データベース設計ができないと「動くけど壊れやすいアプリ」になる
データベース設計ができないと「動くけど壊れやすいアプリ」になる
プログラミング学習では、コードを書くことに集中しがちですが、実務ではデータベース設計がアプリケーションの品質を大きく左右します。
設計が悪いと、データの重複、整合性の崩壊、パフォーマンスの低下など、後から修正するのが非常に困難な問題が発生します。
データベース設計の基本概念
テーブルとは
データベースでは、データを**テーブル（表）**の形で管理します。Excelのスプレッドシートをイメージすると理解しやすいでしょう。
- 行（レコード） — 1つのデータ（例：1人のユーザー情報）
- 列（カラム） — データの属性（例：名前、メールアドレス、年齢）
主キー（Primary Key）
各レコードを一意に識別するための列です。通常はidというカラムを使い、自動で連番が振られます。
- 同じ値が2つ存在してはいけない
- NULLであってはいけない
- 一度決めたら変更しない
外部キー（Foreign Key）
テーブル同士を関連付けるための列です。たとえば、「投稿」テーブルにuser_idを持たせることで、「この投稿は誰が書いたか」がわかります。
テーブル設計の3つのステップ
ステップ1：必要なデータを洗い出す
まず、アプリケーションで扱うデータをすべてリストアップします。
たとえば、ECサイトなら：
- ユーザー情報（名前、メール、パスワード、住所）
- 商品情報（名前、価格、説明、在庫数、カテゴリ）
- 注文情報（注文日、合計金額、配送先）
- 注文明細（商品、数量、単価）
ステップ2：テーブルに分割する
洗い出したデータを、適切な単位でテーブルに分割します。
| テーブル名 | 主な列 |
|---|---|
| users | id, name, email, password_hash, address |
| products | id, name, price, description, stock, category_id |
| categories | id, name |
| orders | id, user_id, total_amount, shipping_address, created_at |
| order_items | id, order_id, product_id, quantity, unit_price |
ステップ3：リレーションを定義する
テーブル同士の関係を定義します。
- 1対多 — 1人のユーザーが複数の注文を持つ（users → orders）
- 多対多 — 1つの注文に複数の商品、1つの商品が複数の注文に含まれる（orders ↔ products、order_itemsで中間テーブルを使う）
- 1対1 — 1人のユーザーに1つのプロフィール（users → profiles）
データベース設計を実践的に学びませんか？
正規化の基本
正規化とは、データの重複や矛盾を防ぐためにテーブル構造を整理することです。
よくある悪い設計の例
商品テーブルにカテゴリ名を直接入れてしまうケース：
| id | name | category_name |
|---|---|---|
| 1 | Tシャツ | トップス |
| 2 | パーカー | トップス |
| 3 | デニム | ボトムス |
この設計の問題点：
- 「トップス」を「アウター」に変更したいとき、すべての行を更新する必要がある
- カテゴリ名の表記揺れ（「トップス」「トップ」）が発生する可能性がある
正規化後の設計
categoriesテーブルを分離し、productsテーブルからはcategory_idで参照する。
- データの更新は1箇所で済む
- 表記揺れが発生しない
- カテゴリに追加情報（説明、画像など）を持たせやすい
未経験エンジニアがやりがちな設計ミス
1. なんでも1つのテーブルに詰め込む
ユーザー情報、住所、支払い情報、注文履歴をすべて1つのテーブルに入れてしまう。テーブルは**「1つのテーマにつき1つ」**が基本です。
2. カラム名が曖昧
data、info、valueなど、何のデータかわからないカラム名は避けましょう。user_name、order_date、total_priceのように具体的な名前をつけます。
3. 削除フラグを使いすぎる
物理削除を避けてis_deletedフラグを使う設計は便利ですが、すべてのクエリでWHERE is_deleted = falseを書く必要があり、バグの温床になります。使いどころを見極めましょう。
データベース設計は「考える力」の訓練
データベース設計は、コードを書く前にアプリケーション全体の構造を考える力を鍛えてくれます。この「設計力」は、エンジニアとしてのキャリア全体を通じて役立つスキルです。
LuaGateの18ヶ月カリキュラムでは、実際のWebアプリケーション開発を通じてデータベース設計を学びます。机上の学習ではなく、自分で設計し、レビューを受け、改善するプロセスを経験できます。
API設計の基礎知識
フロントとバックエンドをつなぐ仕組みを理解する
要件定義からコードまで
仕様書を渡されてからの実務フロー
現場で通用するエンジニアスキル
スクールでは学べない実務力の全体像
LuaGateのカリキュラム
18ヶ月で実務力を身につける実践型カリキュラム
