github twitter email
SQLアンチパターン 読んだ
Jan 1, 2017

インターネットに読めと言われている気がしたので読んだ。

論理設計

一意性と参照整合性に留意する。交差テーブルや従属テーブルを導入する。これは理解できた。
個人的には、ORMはクエリを意識しづらいし使いたくない。

リレーショナルモデルでは、正規化により重複を完全に除去して、結合して頑張ることが正しいとされている。
しかし、実際にはRDBMSは完全なリレーショナルモデルではなく、 結合操作によってパフォーマンスが出ないことがある。
そのために、あえて正規化をしない「非正規化」の存在を知った。 が、具体的にどの状況で使うのか良くわかっていない。

物理設計

  • FLOAT型は丸め誤差を避けられないので、科学演算でない限りはNUMERIC型を使う
  • マスタテーブルは参照テーブルにして、参照元から外部キー指定する
  • トランザクション処理を考慮して、画像はBLOBとしてデータベース内部で管理する
  • インデックスを貼る場合、闇雲に貼るのではなく、スロークエリログとクエリ実行計画をよく見てから考える

画像の扱い方に関して、最近はS3などのストレージに委譲することが多いため 一概には言えないと思った。
正直、アンビギュアスグループはよくわからなかった…。また読みます

クエリ

  • NULLはUnknownであり、値ではない。NULLの代替を使うのはダメ
  • パフォーマンスのために、全文検索はサードパーティのエンジンを使う
  • DBへのアクセスは減らすべきだが、可読性・複雑性の緩和のために分割クエリを使う
  • 列名は明示する

なんでそもそもNULLが出てきたんだっけ?という問いに自身で明確に答えられなかったので、『理論から学ぶデータベース実践入門』を再読する必要がありそう。

アプリケーション

  • セキュリティのためにパスワードはソルト足してハッシュ化、パスワードリセットはトークンで
  • SQLインジェクションを防ぐためにプリペアドステートメントを使う
  • データベースAPIの戻り値を確認
  • SQLも文章化・バージョン管理・テストをやる
  • データベース処理をカプセル化するドメインモデルを用意する

まとめ

冗長性を排除し、整合性を確保するのが正規化であるが、パフォーマンスは考慮していない。
基本的には整合性を考慮したテーブル設計・クエリ設計をすべきだが、規模感やパフォーマンスのため非正規化することもあり得る。
正規化段階はちゃんと覚える。


Back to posts


comments powered by Disqus