新卒2年目ですががっつりDB設計をすることがあり、その際に思ったことなどをまとめておく。
3層スキーマを意識しておけばよかった
特に設計の内容が変わるわけではないのだが、どこまでやればDB設計を完了とみなしていいかがあまりわかっていなかった。今までの現場経験的なところで各カラムのデータ構造まで決定していれば大丈夫だろう。という曖昧な感覚でDB設計を終わらせてしまっていた。
今思えば3層スキーマに従って、外部設計の画面仕様書作成中は、外部スキーマを決定してるようなものだなー。ER図で論理設計をしているときは概念スキーマを決めているんだなー。じゃああとは内部スキーマの決定だけ必要だからそこまでやればOKだな。といったような道筋を立てて考えるべきだった。
行き当たりばったりになってしまっていたので今後注意したい。
「達人に学ぶDB設計」3層スキーマ(外部スキーマ、概念スキーマ、内部スキーマ)とは何か？ | bbh
複数テーブルを跨いだページネーション設計が難しかった
3つあるテーブルのレコードを一つのまとまりとしてページネーションさせて画面に表示するという要件があった。ただ自分の思いつく限りだとページネーション用の共通テーブルで3つのテーブルを管理するという方法しか思いつかなかった。
何か共通テーブルを作らずにできる方法があれば知りたい。
フレームワークがしっかりしてるならアンチパターンもある程度受け入れた方が実装が楽だし綺麗になる
「SQLアンチパターン」本の信者であるが故にポリモーフィック関連のアンチパターンに敏感になりすぎていて、フレームワークでカバーできることを受け入れられてなかった。（フレームワークでカバーしているという依存状態がなんか嫌だった）
Laravelにはポリモーフィックリレーションなるものがあり、これを使う前提で設計していれば実装量は大幅に減らすことができたのではないかなと反省している。
今後も後悔などあれば追記していきます。
パフォーマンスやインデックスの貼り方とかで何か追記できることが今後増えればいいなと思っている。
