その他

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

参考書の「物理設計」は今回はスキップする。 参考書の「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」