ほとんどのエンジニアは「Staticオジサン」よりひどい３

前回の続き。

目次

正解はこうなる

※ 私は左辺、右辺を揃えますが、揃えなくてもOK。

削除フラグで絞り込みたい訳ではないので、「削除フラグ ＝ 0」という条件は、抽出条件ではなく、結合条件なのです。

イメージはこうなる

削除フラグで抽出してないことに注目してください。

つまりこれはバグ！！

LEFT OUTER JOIN のとき、右に置いたテーブルがWHERE句に入ると、外部結合を打消してしまいます。

ですから、外部結合を期待しているのか、INNER JOIN との使い分けが面倒で決め打ちしているのか、ソースだけでは意図が分からない。

いずれにしても矛盾したバグなのです。

「Staticオジサン」はStatic決め打ち

「Staticオジサン」は、Static決め打ちだったのですが、LEFT JOIN 決め打ちで作られているシステムはいくらでもあります。

例えば、WordPress のようなユーザ数が多い OSS でも不用意に決め打ちしている LEFT JOIN はあります。

ちなみにWordPressはこんな変換をしています

WordPressでは、強制的にINNER JOINをLEFT JOINに変換しています。

しかし、WordPressではMySQLが採用されることが多く、MySQLでは IN （サブクエリー）が遅くなりがちで、INNER JOIN（サブクエリー）の方が高速に処理されるというセオリーがあるのですが、それをやるとバグになります。

この変換自体がバグと言えます。（「バグは夜更け過ぎに仕様に変わった」タイプですけどね）

WordPress のような LEFT JOIN 決め打ちは、会社や、プロジェクトの共通仕様に、「JOIN は LEFTにすること」と書かれていることもしばしばあります。

「間違った使い方」という意味では、Static 決め打ちも、LEFT JOIN 決め打ちも、どちらも同じです。後から調査してメンテナンスが大変なのも、どちらも同じです。

しかし、違うのは Static の決め打ちは、それ自体はバグではないけれど、LEFT JOIN の決め打ちは、WordPress のようにバグになるのです。

ですから、間違いに気づいてないエンジニアが「Staticオジサン」を笑う資格はまったくありません。

※ 「Staticオジサン」がSQLをちゃんと理解していたかは知りませんが。

ちなみに、間違っていることの意図を予想して解説をするのはとても難しいですが、最後に LEFT JOIN に変換をしている理由はおそらく以下のスライドの通りでしょう。

世界的にひどい状態です。