現場でDBを利用したシステムに携わった後に読むのが良い。なので初心者よりも中級者向けの本。
現場で可動しているシステムがアンチパターンだからといって設計変更になるケースは多くない。特に規模の大きいシステムであればなおさら。なので、実務で得られた設計や手法の問題点を本書で復習し次に活かすのが最適だと感じた。
交差テーブルの利用を避けたいがためにカンマ区切りの値が入った属性を格納するのは、区切り文字やデータ型による格納上限があったりと拡張性が狭まる。正規化して交差テーブルを作成した方がインデックスも利用できるしメリットが多い。
キーワードなどの親子関係を持つテーブルの構成は入れ子集合や閉包テーブルなど有名な設計方法がある。システムの要件に合わせてメリット・デメリットを考慮して選択するのが良い。他の設計に比べて扱い易い閉包テーブルから検討して見るのも悪くない。
JOIN構文で結合条件で利用するカラム名が同じ場合USINGを使うと簡潔になる。ON構文が省略できるため。
auto incrementを利用しidという疑似キーを利用するのは良くある。主キーと疑似キーが混同して利用され煩雑になる可能性を孕んでいる。一部のフレームワークのように疑似キーを主キーとして利用するルールが統一されているのであれば良い。単にidという名ではなくテーブル名にちなんだカラム名を付けるのが良い。
親テーブルのレコードを削除したけど子テーブルのレコードは存在したままになり、検索結果の集計に不適切になるのは、外部キー制約が適切ではない。参照整合性を保つためにも、適切な外部キー制約を付ける。外部キー制約付与によって大きなオーバーヘッドになることはない。
RDBで名前/キーのペア専用の汎用的なテーブルは適さない。必須属性・外部キー制約が使えず参照整合性を維持できない。名前/キーのペアが増えるに従ってJOINの数が増えてSQLが肥大化する。STIや各テーブルに共通の項目をまとめた基底テーブルを利用するCTI、拡張性が高いが絞り込みやソートが難しくなるJSONの利用などを検討する。または、MongoなどのスキーマレスなDBを検討する。
レコード数が多いテーブルのパフォーマンス向上に水平・垂直パーティションが役立つ。
水平についてはシャーディングが有用。例えば、年毎にシャーディングしてレコードを分かりやすく分散。
垂直の場合はTEXTやBLOBで格納されている列を外に出すことを検討する。ワイルドカード(*)で検索が走るとTEXTやBLOBのカラムが参照され重くなる原因になる。
float型は数値が丸まるので、10億倍すると予期せぬ値が返ってくる場合がある。そのため、固定制度の小数点を定義できるnumeric型を使う。
ENUMやCHECK制約は値の種類が増えたり、削除が発生した際に既存のレコードへの対応だけでなく、スキーマの定義変更も必要になるので使う機会はほとんどない。
RAND関数をソート順をランダムにするのは、テーブルスキャンによるソートになり高コスト。また、ソートにインデックスの恩恵も得られない。RDB側でなくアプリケーション側で対応するのが現実的。
複雑なクエリを作成して1発で結果を取得するのは綺麗だが変更に弱い。細かく分解して結果を結合させた方が保守性は高い。
24章のアクティブレコードの話はフレームワーク利用者は一読しておくと参考になる。
モデルがDB操作を簡便にするアクティブレコードという機能を持っている。
フレームワークを利用しているとモデルは1つのテーブルに対するDB操作を担っているように見える。
しかしこれは適切ではなく、モデルはアクティブレコードの機能を持っていて、必要に応じたテーブルへの操作をするものという捉え方の方が適切。
コントローラー側で、次々とモデルを呼び出す処理がある場合は要注意。疎結合、高凝集性を考慮し、それらをまとめるモデルを作成するのが妥当。
Kindle 端末は必要ありません。無料 Kindle アプリのいずれかをダウンロードすると、スマートフォン、タブレットPCで Kindle 本をお読みいただけます。
-
Apple
-
Android
-
Android
無料アプリを入手するには、Eメールアドレスを入力してください。
