育児本を購入しに行った書店で見つけた「理論から学ぶデータベース実践入門 – リレーショナルモデルによる効率的なSQL」という本の読書logの続きです！
私の備忘録として、勉強になった内容と個人的な感想をまとめています。
あくまでも備忘録なので、詳しく勉強したい方は実際に書籍を手に取ってみてください🙇♀️
※イタリック体の文字は私の感想です。
第6章 ドメインの設計戦略
- ドメインとは、属性が取り得る値の集合のことである。
- ドメインの要素はどのような構造を持つデータでも良いが、明確な値を持つものに限られる。そのため、NULLやポインタは要素として利用できない。
→ドメインの定義として、今後の議論のためにも理解しておきたいです。
- ドメイン設計の流れ
- ドメイン設計は設計者による恣意的な作業である、と言うことを理解する。
- アプリケーションの要件ならびに設計を理解する。
- アプリケーションで永続化が必要なデータを洗い出す。
- データの本質に適したデータ型や桁数を選択する。
- 数値型のIDを文字列型のカラムで定義する、などはよくあるアンチパターンなので注意する
- CHECK制約で値が取りうる範囲を限定する方法も有効
- 適切な属性の名前をつける。
- 必要に応じてDBをリファクタリングする。
→データ型や桁数に、画面やアプリケーションの処理の都合を持ち込んでしまうことは、ありがちな事象ですね。
→CHECK制約はあまり利用したことがないので、活用してみようかな。
- DB設計は、DBAや上流工程の担当者ではなく、開発者が受け持つべき作業である。
→私も概ね同意です。実際にDB設計を担当できない場合でも、設計が確定する前にレビューをして、ともにブラッシュアップできるような関係性を設計者と築けるように努力します。
- ナチュラルキーが議題領域内で一意性を担保できるのであれば、ナチュラルキーをIDとして利用して全く問題ないが、一意性を担保できるかは吟味が必要である。
- ナチュラルキーをIDとして利用できるのにサロゲートキーを新たに作成することは、SQLにてインデックス更新のオーバーヘッドが高くなるので避けたい。
→ナチュラルキーでは見栄えが悪いからと言う理由でサロゲートキーを作成したことがあるので、反省しています。。。
- 書籍のISBNは重複している場合がある。
→失礼ですがちょっと面白かったです。
第7章 NULLとの戦い
- NULLは「値が存在しない」または「値が不明」ということを示すマーカーである。
- リレーショナルモデルには存在せず、SQLのテーブルにだけ存在する。
- 空集合とは別の概念である。空集合は要素が0個の集合である。
- リレーショナルモデルは2値論理（真と偽）をベースにしているので、NULLが含まれる3値論理はリレーションモデルにとって不適切である。
→この説明で、NULLに関する理解の正確さが向上したと感じます。マーカーという表現がしっくりきました。
- NULLは値ではないので、
- NULL値と言う表現は不適切である。
- ==演算子で比較するのではなく、IS NULLやIS NOT NULLで判定する。
→上記2点（特に下）はずっと気になっていたので、すっきりしました！
- NULLが存在すると、RDBMSのオプティマイザのパフォーマンスが下がる。
→NULLに対する演算がクエリ中に含まれると、諸々の制約がかかることがあるよなと思いました。
- NULLの代わりにデフォルト値を設定する方法は、不具合や混乱の元になる技術負債である。
- 外部結合をした場合など、どうしてもNULLの発生を排除できない場合もある。
→NULLの代わりに空文字を設定するというようなことを、私自身もやってしまっていたかもしれません。。。
第8章 SELECTを攻略する
- SELECT句は厄介な存在である。それは、多機能かつ柔軟性が高いためである。
- 集約関数、サブクエリ、などが厄介さの原因の代表例。
→厄介だなんて考えたこともありませんでしたが、思い起こせば、HAVING句やサブクエリの理解や使い方に苦戦したな。。。
- クエリ内の各句の実行順序は、論理的な評価順序と必ずしも一致するわけではない。
→論理的な評価順序と、実行計画等の結果を、混同しないように心がけたいですね。
- リレーショナルではない操作として、FROM句内の集約のサブクエリ、ORDER BY、ROWIDやROWNUMなどが挙げられる。
→昔、ROWNUMに依存したロジックを書いた（書かされた？？）ことがあったのも、良い思い出？
- 可能な限り、リレーショナルモデルの範疇で処理を記述し、リレーショナルモデルに沿った処理を先に実行する。
ここまでの感想
普段の業務でも、ドメインの設計が不適切であったり、NULLが散見されるテーブルを扱う場合は、SELECT句が複雑になることが多いなと感じます。
それを改善するためにはDBのリファクタリングをした方が良いのですが、アプリケーション側の修正で対応できる場合も多いので、本質的な改善にはならず技術負債を蓄積させてしまいがちです。
DBのリファクタリングは気が重いですが、システムを健康で長生きさせるためにも、積極的に提案していこうと思います！
以上
