はじめに
『SQLアンチパターン』を読んで学んだことをメモしていきます。
全体の感想
技術書として非常に読みやすく、内容がスムーズに頭に入ってきます。約8割は既に知っている内容でしたが、「知っている」と「実践できる」は別物です。この本を通じて頭の中を整理することで、自分のSQLスキルが一段階向上したと感じました。
若干古い内容もありますが、おすすめできる本です。
メモ
以下の内容は自分で下書きしたものをChatGTPに清書してもらいました。
ツリー構造の格設計メリデメ
ツリー構造の各設計手法とそのメリット・デメリット
コメントに対するコメント、さらにそのコメントに対するコメント、といった形でデータがツリー構造になる場合、ユースケースに応じていくつかの設計手法が考えられます。
中には普段使う機会が少ない方法もありますが、知識として持っておくことで、必要な場面で役立つでしょう。特に「閉包テーブル」方式は、現時点でのベストプラクティスとされています。
(P30)
とりあえずIDはNG
例えば、commentsテーブルの主キーを「id」とするか「comment_id」とするか、という議論があります。
一般的にはテーブルの主キーを単に「id」とするケースが多いですが、これにはアンチパターンとされる側面もあるとのこと。こういった命名ルールについては、組織全体で認識を合わせることが重要です。
私自身は「comment_id」のように具体的な名前を使用する方が好ましいと考えています。ただし、これまでの経験上、「id」を用いる方が一般的だと感じます。
また、「comment_id」のように主キーに具体的な名前を付けると、テーブルを結合する際に USING 句が使用できるようになる点は確かにメリットです。ちなみに、USING 句については、本書で初めてその存在を知りましたが、シンプルで読みやすいクエリを書く上で有用な機能だと感じました。
外部キー嫌い
「外部キー制約を省略すれば、データーベース設計がシンプルになり、柔軟性が高まり、実行速度が速くなると思っている読者もいるかもしれません。しかし、そこには代償があり、代償は別の形で支払わなくてはならないのです。つまり、開発者であるあなたに、参照整合性を保証するためのコードを書く責任が生じるのです。」
（引用:アンチパターン 第4章)
この指摘には私自身も考えさせられます。私の現場でも、外部キー制約を付けないことが多いです。これは、少し前までPostgreSQLではパーティションテーブルに外部キー制約を設定できなかったため、その名残が影響しているのかもしれません。（現バージョンでは外部キー制約がサポートされています。）今一度、設計を見直す必要性を感じています。
## ラウンディングエラー（丸め誤差）
FLOAT型では、実測値と理論値の間に誤差が生じる場合があります。
例えば、x = 59.95 のとき、x * 100000000 の結果が 59950000762.939 となるケースがあります。
これは、FLOAT型が内部で2進数を用いて小数を表現する仕組みによるものです。2進数では少数の正確な表現が難しく、1/2, 1/4, 1/8, 1/16,... のような組み合わせで近似を行うため、丸め誤差が発生します。
本書では、こうした特性によって利子の計算などの金融処理に支障をきたす可能性がある点を指摘しています。正確な計算が必要な場面では、NUMERIC や DECIMAL 型を使用することが推奨されています。
この知識は、データ型選択の際に慎重さが求められる重要なポイントだと感じました。
WHERE A = NULLがNGな理由
WHERE A = NULL がなぜNGなのか、これまで理解していませんでしたが、本書の説明は非常にわかりやすいものでした。
NULL = A の例
オリバーの年齢が不明だとします。
Q: オリバーは10歳ですか？
A: わかりません。
→ 結果は NULL となります。
NULL = NULL の例
オリバーの年齢とケイシーの年齢がどちらも不明だとします。
Q: オリバーの年齢はケイシーの年齢と同じですか？
A: わかりません。
→ 結果は NULL となります。
このように、NULL は「不明」を表すため、WHERE A = NULL のような比較では真偽を確定できず、条件として使用することは適切ではありません。その代わりに、IS NULL を使用して明示的に確認する必要があります。
この説明を読んで、NULL の扱いについて理解が深まりました。
グルーピング
group byやjoinを利用した集計処理の方法が列挙されている。(P162)
これは別の機会に手元で実行計画を確認したいところです。
全文検索のアンチパターン
実務で検索機能を作った記憶はないが、SQLのLIKE句と%を利用した検索は遅いのは間違いないでしょう。SQLだけで高速な検索エンジンを作るのは難しいのでサードパーティやキャッシュなどの工夫が必要。この辺は『システム設計の面接試験』も参考になる。
最後に
この本はタイトルもキャッチーで以前から読みたかった本でした。
内容も理解できたし、知っている内容も多かったので自信がつきました。
今後はリファクタリングとかコードのお作法的な本が積んであるので読み進めたいです。