A DB設計

郵便番号 >< 都道府県テーブル

xxx

データベースを制するものはシステムを制す。

参考書の「物理設計」は今回はスキップする。
参考書の「ER図」は今回はスキップする。
参考書の「インデックス設計」は今回はスキップする。

■データ中心アプローチ DOA（Data Oriented Approach）
プログラムより前にデータの設計から始める方法論。現代の主流。
プログラムを先に作ってデータ設計を後回しにする方法はうまくいかない。

■命名規則
テーブル名はすべて複数形または複数名詞にすること。（世界的に有名なDB設計者）
複数形または複数名詞を命名できないテーブルはそもそも適切なテーブルではない。

スキーマ

3層スキーマ … 外部、内部、概念。

■外部スキーマ
ユーザからみたデータベース。
ビュー。

■概念スキーマ
開発者からみたデータベース。
テーブル定義。
データ設計において重要なスキーマ。

■内部スキーマ
データの物理的配置。

論理設計

エンティティの抽出 → エンティティの定義 → 正規化 → ER図の作成

■エンティティの抽出
どのエンティティが必要か洗い出す。（「会員」、「受注」）
エンティティはテーブル単位になる。

■正規化
データの冗長性を排除し一貫性と効率性を保持する。
基本的には必ず正規化すること。第二正規系までは必須。
どうしても検索パフォーマンスを上げたい場合のみ結合を避けるため非正規なテーブルを作っても良い。
・第二正規系
関数従属を排除。社員テーブルに部署IDと部署名カラムがあれば、部署テーブルを作成し部署名を部署テーブルに移す。

テーブル設計

■主キー
主キーは必ず存在しなければならない。一意であること。
不変であること。
主キーが必要なさそうなデータテーブルでも主キーを設定すること。検索で重複起きても知らんよ。
自動採番される意味を持たないIDのようなキーをサロゲートキーと呼ぶ。
色々なプロジェクトを渡り歩いてきたが、Laravel有無関係なく、主キー名を単に「id」としているプロジェクトはなかった。
「テーブル名＋ID」が多い。

配列型は使用しないこと。
意味的に文字列内で分割できるカラムは分割すること。姓と名や、メールアドレスとドメイン。

■外部キー
必ず設定すること。
存在しないデータの登録を防ぐ。制約。
社員テーブルの部署カラムに対する部署テーブルの部署コードのようなイメージ。

■NotNull制約
可能な限りNotNullであること。Nullはバグの温床。

MySQL : bool値を入れるカラムには「tinyint(1) … intのようなもの」を利用する（要確認）

テーブル名

詳細「sample_details」

カラム名

flgやkbnは使用しない。
削除フラグ「is_deleted」。
登録日「created_at」
更新日「updated_at」
登録者「created_by」
更新者「updated_by」