-
Notifications
You must be signed in to change notification settings - Fork 0
DB設計
データベースを制するものはシステムを制す。
参考書の「物理設計」は今回はスキップする。
参考書の「ER図」は今回はスキップする。
参考書の「インデックス設計」は今回はスキップする。
■データ中心アプローチ DOA(Data Oriented Approach)
プログラムより前にデータの設計から始める方法論。現代の主流。
プログラムを先に作ってデータ設計を後回しにする方法はうまくいかない。
■命名規則
テーブル名はすべて複数形または複数名詞にすること。(世界的に有名なDB設計者)
複数形または複数名詞を命名できないテーブルはそもそも適切なテーブルではない。
3層スキーマ … 外部、内部、概念。
■外部スキーマ
ユーザからみたデータベース。
ビュー。
■概念スキーマ
開発者からみたデータベース。
テーブル定義。
データ設計において重要なスキーマ。
■内部スキーマ
データの物理的配置。
エンティティの抽出 → エンティティの定義 → 正規化 → ER図の作成
■エンティティの抽出
どのエンティティが必要か洗い出す。(「会員」、「受注」)
エンティティはテーブル単位になる。
■正規化
データの冗長性を排除し一貫性と効率性を保持する。
基本的には必ず正規化すること。第二正規系までは必須。
どうしても検索パフォーマンスを上げたい場合のみ結合を避けるため非正規なテーブルを作っても良い。
・第二正規系
関数従属を排除。社員テーブルに部署IDと部署名カラムがあれば、部署テーブルを作成し部署名を部署テーブルに移す。
■主キー
主キーは必ず存在しなければならない。一意であること。
不変であること。
主キーが必要なさそうなデータテーブルでも主キーを設定すること。検索で重複起きても知らんよ。
自動採番される意味を持たないIDのようなキーをサロゲートキーと呼ぶ。
色々なプロジェクトを渡り歩いてきたが、Laravel有無関係なく、主キー名を単に「id」としているプロジェクトはなかった。
「テーブル名+ID」が多い。
★Laravelなら主キーはIDにしなさい。マイグレーションで外部キー制約の関数が数値型にしか対応していないから普通に後悔するよ
実践: 主キーに意味を持たせた場合、クライアントのわがままで主キー値を変更したいとか言われて大惨事になりました。
配列型は使用しないこと。
意味的に文字列内で分割できるカラムは分割すること。姓と名や、メールアドレスとドメイン。
■外部キー
必ず設定すること。
存在しないデータの登録を防ぐ。制約。
社員テーブルの部署カラムに対する部署テーブルの部署コードのようなイメージ。
■NotNull制約
可能な限りNotNullであること。Nullはバグの温床。
MySQL : bool値を入れるカラムには「tinyint(1) … intのようなもの」を利用する(要確認)
詳細「sample_details」
flgやkbnは使用しない。
削除フラグ「is_deleted」。
登録日「created_at」
更新日「updated_at」
登録者「created_by」
更新者「updated_by」