  |
https://anond.hatelabo.jp/20240507125309
はい。
ではなく、SQLは処理じゃなく、定義であることを理解するのが大切。
何の定義かと言えば、リレーショナルデータモデルへの演算定義なんだよ。この演算には、関係代数という演算を使う。
なぜ定義だと認識する必要があるかという、Selectは出力でも何でもなく、射影という演算の一部なんだよ。
"+3" とかと一緒
で、関係代数演算は順位にもちろん意味がある。最初に"射影"して"選択"かけたら全く別になる。
SQLは、この演算順位を、SelectやWhereの中で状況によって意味が変わる。という出鱈目なカバーで逃げた。Order byで悩んだろ。
さらに言えば、苦肉の策でWhereのパチモンはどうしても2回必要でHavingを作ったのよ
本来で言えば、この演算は、選択-結合-射影-結合といくらでも出来る。
「足し算は頭に一回書いてください。複数使う時はかっこつけて下さい。ちなみに、掛算を一緒に使うと足し算の意味が変わり場合によってはエラーです」みたいな安直な構造定義しちゃってるの。
リレーショナルモデルへの演算としてだダサダサで、リレーショナルモデルの演算の複雑さではなくSQLという表現の都合で人類の頭に負荷かけ続けてる。
出力が頭にあるのは便利(間違い)。英語だから(間違い)。って言われると何言ってるんだーって、ちょい昔のまともなデータベースエンジニアなら普通にキレてた案件
https://b.hatena.ne.jp/entry/s/www.docswell.com/s/hoxo-m_inc/Z4Q8NL-2024-05-06-203800 まともにコンピューターサイエンスやってSQL使ってれば 「わかるー射影はステップの最後なのに、selectに名前変更とか拡...
https://anond.hatelabo.jp/20240507125309 はい。 ではなく、SQLは処理じゃなく、定義であることを理解するのが大切。 何の定義かと言えば、リレーショナルデータモデルへの演算定義なんだよ。こ...
「わかるー射影はステップの最後なのに、selectに名前変更とか拡張とか全部乗せて先に書くのキモいよねー」 これ書いてる人誰もいなかったけど
確かに書くときはselect句を最初に書きにくいことはよくある。 でもそれだけのことでで、いったん空白にしておいてfrom以降を書く程度の手間でカバーできてる。（その点ではそのツール...
わかるー射影はステップの最後なのに、selectに名前変更とか拡張とか全部乗せて先に書くのキモいよねー
35
