インターネットに読めと言われている気がしたので読んだ。
論理設計
一意性と参照整合性に留意する。交差テーブルや従属テーブルを導入する。これは理解できた。
個人的には、ORMはクエリを意識しづらいし使いたくない。
リレーショナルモデルでは、正規化により重複を完全に除去して、結合して頑張ることが正しいとされている。
しかし、実際にはRDBMSは完全なリレーショナルモデルではなく、
結合操作によってパフォーマンスが出ないことがある。
そのために、あえて正規化をしない「非正規化」の存在を知った。
が、具体的にどの状況で使うのか良くわかっていない。
物理設計
- FLOAT型は丸め誤差を避けられないので、科学演算でない限りはNUMERIC型を使う
- マスタテーブルは参照テーブルにして、参照元から外部キー指定する
- トランザクション処理を考慮して、画像はBLOBとしてデータベース内部で管理する
- インデックスを貼る場合、闇雲に貼るのではなく、スロークエリログとクエリ実行計画をよく見てから考える
画像の扱い方に関して、最近はS3などのストレージに委譲することが多いため
一概には言えないと思った。
正直、アンビギュアスグループはよくわからなかった…。また読みます
クエリ
- NULLはUnknownであり、値ではない。NULLの代替を使うのはダメ
- パフォーマンスのために、全文検索はサードパーティのエンジンを使う
- DBへのアクセスは減らすべきだが、可読性・複雑性の緩和のために分割クエリを使う
- 列名は明示する
なんでそもそもNULLが出てきたんだっけ？という問いに自身で明確に答えられなかったので、『理論から学ぶデータベース実践入門』を再読する必要がありそう。
アプリケーション
- セキュリティのためにパスワードはソルト足してハッシュ化、パスワードリセットはトークンで
- SQLインジェクションを防ぐためにプリペアドステートメントを使う
- データベースAPIの戻り値を確認
- SQLも文章化・バージョン管理・テストをやる
- データベース処理をカプセル化するドメインモデルを用意する
まとめ
冗長性を排除し、整合性を確保するのが正規化であるが、パフォーマンスは考慮していない。
基本的には整合性を考慮したテーブル設計・クエリ設計をすべきだが、規模感やパフォーマンスのため非正規化することもあり得る。
正規化段階はちゃんと覚える。