データベース設計ができないと「動くけど壊れやすいアプリ」になる

データベース設計ができないと「動くけど壊れやすいアプリ」になる

プログラミング学習では、コードを書くことに集中しがちですが、実務ではデータベース設計がアプリケーションの品質を大きく左右します。

設計が悪いと、データの重複、整合性の崩壊、パフォーマンスの低下など、後から修正するのが非常に困難な問題が発生します。

データベース設計の基本概念

テーブルとは

データベースでは、データをテーブル（表）の形で管理します。Excelのスプレッドシートをイメージすると理解しやすいでしょう。

• 行（レコード） — 1つのデータ（例：1人のユーザー情報）
• 列（カラム） — データの属性（例：名前、メールアドレス、年齢）

主キー（Primary Key）

各レコードを一意に識別するための列です。通常はidというカラムを使い、自動で連番が振られます。

• 同じ値が2つ存在してはいけない
• NULLであってはいけない
• 一度決めたら変更しない

外部キー（Foreign Key）

テーブル同士を関連付けるための列です。たとえば、「投稿」テーブルにuser_idを持たせることで、「この投稿は誰が書いたか」がわかります。

テーブル設計の3つのステップ

ステップ1：必要なデータを洗い出す

まず、アプリケーションで扱うデータをすべてリストアップします。

たとえば、ECサイトなら：

• ユーザー情報（名前、メール、パスワード、住所）
• 商品情報（名前、価格、説明、在庫数、カテゴリ）
• 注文情報（注文日、合計金額、配送先）
• 注文明細（商品、数量、単価）

ステップ2：テーブルに分割する

洗い出したデータを、適切な単位でテーブルに分割します。

ステップ3：リレーションを定義する

テーブル同士の関係を定義します。

• 1対多 — 1人のユーザーが複数の注文を持つ（users → orders）
• 多対多 — 1つの注文に複数の商品、1つの商品が複数の注文に含まれる（orders ↔ products、order_itemsで中間テーブルを使う）
• 1対1 — 1人のユーザーに1つのプロフィール（users → profiles）

正規化の基本

正規化とは、データの重複や矛盾を防ぐためにテーブル構造を整理することです。

よくある悪い設計の例

商品テーブルにカテゴリ名を直接入れてしまうケース：

この設計の問題点：

• 「トップス」を「アウター」に変更したいとき、すべての行を更新する必要がある
• カテゴリ名の表記揺れ（「トップス」「トップ」）が発生する可能性がある

正規化後の設計

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を書く必要があり、バグの温床になります。使いどころを見極めましょう。

データベース設計は「考える力」の訓練

データベース設計は、コードを書く前にアプリケーション全体の構造を考える力を鍛えてくれます。この「設計力」は、エンジニアとしてのキャリア全体を通じて役立つスキルです。

ゆめさくエンジニアの18ヶ月カリキュラムでは、実際のWebアプリケーション開発を通じてデータベース設計を学びます。机上の学習ではなく、自分で設計し、レビューを受け、改善するプロセスを経験できます。

API設計の基礎知識

フロントとバックエンドをつなぐ仕組みを理解する

要件定義からコードまで

仕様書を渡されてからの実務フロー

現場で通用するエンジニアスキル

スクールでは学べない実務力の全体像

ゆめさくエンジニアのカリキュラム

18ヶ月で実務力を身につける実践型カリキュラム