の最適化に参加します。 例えば、データベース部門を管理する従業員の名前を見つけるために、あなたがこれを行うだろう：
名前（ Mgr_ssn（ DNAME = 'データベース'（学科））⨝ Mgr_ssn = SSN従業員） をのような何かをすることも同様に正しいことかどう
は、だから私は思ったんだけど：
名 （ Mgr_ssn（ DNAME = 'データベース'（学科））⨝ Mgr_ssn = SSN（ SSN、名前従業員））
これは、従業員は、他の多くの属性を持っている、もちろん想定しています。そうすることで、システムが、従業員の他のすべての属性に結びつくことを心配する必要がなくなるため、時間が節約できると思うでしょう。私はこれまでに結合の右側にこのような射影を見たことはありませんし、それが受け入れ可能か不必要なのか不思議です。リレーショナル代数は、私が参加する操作の多くが参加するの右側にテーブルを最適化し、そして唯一の左のように見えたことはありません学校のための私の教科書で見てきた
ほとんどのオプティマイザは深い加入左考慮システムR・オプティマイザを使用しています。そのため、右の結合が決して見られません。オプティマイザは、（オプティマイザが最善の解決策が見つからない、彼らは最悪のものを回避しようと）すぐに合理的に許容可能な解決策を見つけたいので
すべてのオプションの探索空間が指数関数的です。
P.S.左ディープ・ジョインを使用する理由は、結果をディスクに書き込む必要なくパイプライン化できるため、I/Oが節約されるからです。
まともなクエリオプティマイザは、処理されるデータを最小限に抑えるために、あまりにも時々突起部を適切な制限を押し下げ、となります。また、オプティマイザは自動的にそれを行い、結果は同一であるため、関係代数の式を最適化する必要は特にありません。二テーブルで
は、このような配列は、部門に参加する前に突起を形成することに利点があるであろうことは明らかではないが加わります。 E.SSN = D.Mgr_SSNを使用してEmployee内の単一の行を検索します（おそらく単一の）Dname = 'Database'を持つ部門を検索します。しかし、サブ式が複数回使用された場合は、それを実行する価値があります。
また、設計がひどいことにも注意してください。データベース設計の結合フィールドとしてSSNほど重要なものを決して使用しないでください。 PCIチームにはフィット感があります！しかし、おそらく、名前は長い昔の昔からの二日酔いですが、コンテンツは生成されたサロゲートであり、実際のSSNはEmployee.RealSSNに格納されています（暗号化されていても、承認されたユーザーだけがそれを選択できるように、列に対する権限も有効です）。
システムRのプロトタイプ以降、オプティマイザが進化しました。 –