達人に学ぶDB設計を一通り読むことができましたため、読んでみて、良かったところや学んだこと、難しかったことを記載します！
良かったところ
技術のメリットだけでなく、デメリット、目的が記載されているところ
例えば、正規化のメリットとして、データの整合性を維持することはすっきりわかるSQLにも書かれておりましたが、正規化のデメリットも書かれていたことです。正規化をすることで、テーブルが複数に分割されるため、複数テーブルを参照する際、結合を使います。 結合は負荷が高い処理のため、パフォーマンスが悪くなってしまう原因であることを知りました。
また、 第一正規系の目的は一つのカラムに一つの値にすることで、一意にデータを絞ることができます。
第二正規系の目的は異なるレベルのエンティティを明確にテーブルとして分けることです。 例えば、会社と社員テーブルを一つとした場合、会社に商社Cだけあるものの、社員がいないというデータはテーブルに格納できません。なぜなら、社員情報がないため、主キーにデータが入らないからです。しかし、会社と社員を別テーブルにすれば、会社テーブルだけにC商社を入れることができます。
ちゃんと目的とメリット、デメリットを抑えて、技術選定できるようになりたいです💪
インデックスを貼ると効果的なカラムについて詳しく書かれていたところ
スキリわかるSQLにはインデックスを貼ると効果的なのは結合条件のカラムやWHEREの完全一致、前方一致、ORDER BYなどが書かれておりましたが、本書ではさらに詳しく書かれていて、勉強になりました！
以下のカラムにインデックス(B-tree)を貼ると効果的です。
- データ量が多いことです。約1万件以上になる場合。1万件以下の場合、インデックスを使用せず、フルスキャンの方がパフォーマンスが良いからです。
- データの種類（カーディナリティ）が多いこと。例えば、男、女、それ以外だとカーディナリティは3と少ないですが、受付日が365だとカーディナリティが高い方です。
カーディナリティが高くてもデータ量に偏りがある場合はインデックスの効果発揮されません。例えば、カーディナリティが100だとしても99%が100という値で残りの1％が1〜99だとインデックスの効果が発揮されません。
わかったこと
多段ビューはアンチパターンであること
前職でデータマート関連のシステム開発で多段ビューが使用されており、仕様を把握するのが難しいと思っていたのですが、やはりアンチパターンだったということを知れました😅
アンチパターンなのは仕様把握が困難なだけでなく、パフォーマンスも悪いためです。
ビューにはSELECT文が保存されております。また、そのビューをSELECTして、ビューからSELECTしているため、それが多段ビューですと複数回SELECTが行われるため、パフォーマンスが悪くなってしまうことを知りました。
それでは多段ビューを使用しないためにはどうすれば良いかというとマテリアライズドビューを使用した方が良いことです。
マテリアライズドビューはビューという名前がついているものの、テーブルにデータが入っております。ビューだとユーザがSQLを発行するたびに、ビューに定義されたSQLが発行されますが、マテリアライズドビューはビューに定義されたSQLの実行結果をテーブルに格納している状態です。そのため、ビューのように2回SQLを発行せず、パフォーマンスが悪化しません。
デメリットとしては、マテリアライズドビューに格納されているデータをリフレッシュする必要があります。
列持ちテーブルはバットノウハウではなく、グレーノウハウであること
列持ちテーブルとは例えば、扶養家族テーブルの列に子供1、子供2、子供3などがあるテーブルのことです。
個人的には正規化できるから、アンチパターンかと思っていたのですが、メリット・デメリットを考慮した上で使用するにはグレーノウハウとのことです。
メリットはテーブルの中身を把握しやすいことです。また、テーブルからアプリケーションへデータを取り込む際にテーブル結合せず、SELECTするだけでデータが取れることです。
一方、デメリットは拡張性が低いことです。テーブルに列が増減したら、それによってアプリケーション側にも改修が必要です。また、NULLが入るカラムもあるため、SQL文を混乱させます。
難しかったこと
第9章の入れ子集合モデルで作成されたテーブルを参照する際に、自己結合とNOT EXISTSを使ったSQLが上手く理解できなかったため、学習していきます!