本日も引き続き「現場で役立つシステム設計の原則」を読み進めてます。
本日は主にデータベース層の考え方について。
データべース層
要点
典型的なダメテーブル設計
- 既存DBの問題点(意味不明なカラム、NULLが入っている、ダブルミーニング、関係がわからない、テーブルが巨大すぎ)
- 制約(ユニークキーがない、NOT NULLがない、外部キー制約がない)
- 1つのカラムに複数の意味と思われるデータが入っている
- テーブル間の関係がしっかりしていない
基本的には下記のリンクでかいたようなネタ
論理設計のアンチパターン その2
論理設計のアンチパターン
データベースアンチパターン・グレーパターンまとめ
対策
- カラム時の制約を整理(not null,FK,ユニーク他)
- 記録のタイミングが違う場合はテーブルを分ける(正規化に従って全ての情報を１テーブルで持つ必要はない。)
- コト(会員、入出力金額、在庫・・・)の記録を中心に行い、状態(差分の変更)の記録をできるだけ作らない
- UPDATE文をなるべく使わず、INSERTで履歴を追加する
- カラム追加時はテーブルの分割を考える(ただし非正規化が崩れる)
- 複数の更新作業は非同期で行ってもよい(ただし複数のサーバー分割などデメリットもあり)
- 集計はイベントの記録から動的に作成する(ビューや中間テーブルを使わない)
- オブジェクトとテーブルは似てはいるが違うもの
感想
今回はデータベースがらみの話。結構いろいろな本を読んで勉強しまして、半分以上は知っている話だったんですが、UPDATEを使わないってのは初でしたね。確かに今作ってるアプリでも履歴をつくってデータを消さないってのはあるんですけど、INSERTとDELETEだけってのは聞いたことがありませんでした。私がまだ考えを理解できていないだけかもしれませんが、やや原理主義的な感じもしました。
カラムが増える場合はテーブル分割したほうが良い面もありますね。ただ1:1の構成になりますんで、非正規化は徹底されていないです。メリットデメリットをみることが大事かなと思います。
