私は本にあるすべてのデータベース設計のミスを犯しました。その中には二度も犯したものがあります。最悪なのは、悪いデータベース設計はすぐには響かないことです — それは、6ヶ月後に機能を追加しようとして、スキーマのために痛みを伴うマイグレーションなしで不可能であることに気づいたときに痛みを伴うのです。
最初は問題ないように見えるミス
1. すべてを1つのテーブルに格納する
47列を持つ「users」テーブル。名前、メール、住所、好み、サブスクリプション状況、最終ログイン、プロファイル写真のURL、請求情報... 「副メールアドレス」を追加する必要があるとき、列48を追加します。これが技術的負債の始まりです。
論理的なエンティティに分けます：ユーザー、住所、サブスクリプション、好み。より多くのテーブル、よりシンプルなクエリ、より簡単なメンテナンス。
2. リレーションシップを計画しない
「ユーザーは1つの住所を持つ」は、6ヶ月後には「ユーザーは複数の住所を持つ」になります。住所にJSON列を使用している場合、すべてのクエリを書き直す必要があります。別の住所テーブルに外部キーを使用している場合は、1行の変更で済みます。
3. インデックスを無視する
アプリは1,000行で速いです。100,000行では、そのインデックスがないWHERE句が3秒かかります。1,000,000行では、タイムアウトします。フィルタリング、ソート、または結合に使用する列にインデックスを追加します。データベースのパフォーマンス研究によると、インデックスが不足していることが遅いクエリの第1の原因です。
4. 不適切なデータ型を使用する
電話番号を整数として格納する（先頭のゼロが消える）。お金を浮動小数点として格納する（0.1 + 0.2 ≠ 0.3）。日付を文字列として格納する（ソートするのは大変）。最初から正しい型を使用してください — 後で変更するには、すべての行をマイグレーションする必要があります。
デザインプロセス
AIデータベースデザイナー は、SQLを書く前にスキーマを考える手助けをします。アプリケーションのデータ要件を説明し、適切なリレーションシップ、インデックス、およびデータ型を持つ正規化されたスキーマを生成します。
- エンティティをリストする（ユーザー、製品、注文など）
- リレーションシップを定義する（1対多、多対多）
- データ型を慎重に選択する
- 頻繁にクエリされる列にインデックスを追加する
- 6ヶ月後に追加する機能を計画する
正規化：短いバージョン
同じデータを2か所に保存しないでください。顧客の名前が顧客テーブルと注文テーブルの両方に表示される場合、ズレが生じます。一度だけ保存し、外部キーで参照します。