第3章データベース設計の重要性 — なぜ最初に丁寧に作るのか

この章で学ぶこと

データベース設計が後から直しづらい質的な理由を 3 つ挙げられる
「設計時の判断が将来の何に影響するか」を具体例で説明できる
データ設計スキルが AI 時代でも価値を持ち続ける理由を理解する

前提知識

第 2 章システムとデータベースの関係を理解していること。

データベース設計は「建物の基礎」

家を建てるとき、最初に基礎工事をします。基礎が傾いていたら、その上にどんなに立派な建物を建てても安定しません。そして基礎は、建物が完成してから直そうとすると、いったん上を全部壊すことになります。

データベース設計はこの「基礎」に相当します。アプリのコードがどれだけ綺麗でも、テーブル設計が破綻しているとシステム全体が不安定になります。そして運用が始まってから設計を直すのは、運用中のサービスを止めずに基礎を打ち直すのに近い難しさです。

設計ミスが後から直しにくい質的理由

「設計を後から直すのは大変」とよく言われますが、具体的にどういう難しさがあるのでしょうか。Jr が現場で当たるであろう壁を 3 つに整理します。

1. 運用中のサービスを止められない

EC サイトや SNS が「これからテーブル構造を変えるので 3 日間止まります」と言ったら、ユーザーは離れていきます。本番稼働中のシステムでは、ダウンタイムを最小限に抑えながらスキーマ変更とデータ移行を進める必要があり、これが慎重さとコストを増やします。

開発中	運用中
テーブルを `DROP` して作り直せる	既存データを保ったままで変えなければならない
数十件のテストデータだけ	数百万〜数億件の本番データ
「ちょっと止めて」が許される	1 分のダウンタイムも金銭損失 / SLA 違反

2. データ移行のコスト

設計を変えるとき、既存のデータを新しい形に変換する処理を書く必要があります。たとえば「1 つのカラムに姓と名が一緒に入っていたのを、姓と名のカラムに分けたい」という変更を考えてみます。

データを 1 件ずつ読み、姓と名を機械的に分割するロジックを書く
「山田太郎」のように半角スペース区切りなら簡単だが、「山田太郎」(スペースなし) や外国人名 ("Jean-Luc Picard") の例外をどう扱うか決める
移行スクリプトを本番データで動かす前に、本番相当のデータ量でリハーサル
移行中に新規データが入ったらどう扱うか (ロックするか、二重書きするか)

このような移行作業は、設計段階で適切に作っておけば 1 行も書かずに済みます。

3. 影響範囲が広い

データベースは複数のシステム / 機能から参照されることが多いため、テーブル構造を変えると影響範囲がそのまま広がります。

カラム名を変えると、それを使う SQL すべてを書き換える必要がある
カラムを削除すると、過去のレポート集計クエリが動かなくなる
データ型を変えると、アプリ側の型定義 (TypeScript の型 / Java のクラスなど) もすべて変える

設計時なら影響は自分のコードの中だけですが、運用後はチーム全体・複数システムへと波及します。

修正コストの定量比較について

「設計時の修正は運用時の 100 分の 1 のコスト」といった主張をよく見かけます。これは Barry Boehm (1981) のソフトウェア工学の研究が起源ですが、Boehm 自身が 2001 年に「小規模システムでは 5 倍程度に収まる」と訂正しており、近年の研究 (Menzies et al., 2017) では「明確な指数関数的増加は実証されていない」と批判もあります。数値の正確さは保証できないものの、「後ほど直すほうがコストがかかる」という方向性は経験的に同意できる、というのが現状の理解です。

設計時の判断が将来何に影響するか

設計時に決めた小さな選択が、将来どこに効いてくるかを具体例で見てみましょう。

設計時の判断	数年後に効いてくる影響
主キーを `INTEGER` でなく `BIGINT` にする	数十億件まで扱えるか、約 21 億で枯渇するか
メールアドレスを 100 文字でなく 255 文字に	長いメールアドレスのユーザーで登録失敗するかしないか
日時を `TIMESTAMP WITH TIME ZONE` にするか `WITHOUT` にするか	海外展開時にタイムゾーン問題で全データ再計算するかしないか
削除を物理削除でなく論理削除にするか	「うっかり削除した顧客を復元したい」依頼に応えられるか
カラムを `NOT NULL` 制約付きで作るか	不正なデータが入り込むかどうか、入った場合の清掃コスト

これらは「設計時なら 30 秒で決められる」項目ですが、運用後に変更しようとすると、上記の「3 つの質的理由」がすべて立ちはだかります。

データ設計スキルは AI 時代でも価値を持つ

「これからは AI / 機械学習の時代だから、データベース設計の知識はあまり要らないのでは?」という疑問があるかもしれません。実は逆で、AI 時代だからこそ価値が増しています。

1. AI の燃料はデータ

機械学習モデルは大量の良質なデータから学びます。「良質な」とは、構造化されていて、矛盾がなく、関係性が明確に整理されているということ。これはまさにデータベース設計が目指してきたものです。

2. クラウド DB を使っても設計は変わらない

AWS RDS や Google Cloud SQL のようなマネージドサービスは、運用 (バックアップ / レプリケーション / OS パッチなど) を肩代わりしてくれますが、テーブル設計 までは肩代わりしてくれません。むしろクラウドの従量課金では「無駄なインデックスをたくさん作る」「効率の悪いクエリを書く」が直接コストに跳ね返るため、設計の良し悪しが金額で見える化されます。

3. すべてのエンジニアの共通言語

フロントエンド / バックエンド / データ分析 / インフラ — どの専門領域でも「データの形を読む / 議論する」場面は必ずあります。テーブル設計を読めることは、チーム内のコミュニケーションの基礎体力です。

データベース設計ができると何ができるか

本ガイドの 19 章 + 用語集 + 設計テンプレート集を通読すると、これらの土台を身につけられます。

演習

演習 1: 設計を直しにくい場面を考える

あなたが運用中の SNS で、「ユーザー名 (username) を後から追加で『ニックネーム』というカラムに分けたい」という変更を頼まれたとします。発生しそうな困りごとを 3 つ挙げてみてください。

解答例

たとえば次のような困りごとが考えられます。

既存ユーザーの初期値: 既存ユーザーには nickname カラムがないため、初期値を何にするかを決める必要がある (username をそのままコピー / 空にする / ユーザーに後で入力させる)
既存の SQL の書き換え: username を表示している箇所が複数ある場合、nickname を優先 → なければ username というロジックに変更する必要がある
過去のリンク・通知メッセージ: 「@username で通知」のような既存機能が、ニックネーム導入後にどう振る舞うかを設計し直す必要がある

ありがちな間違い: 「カラムを追加するだけだから簡単」と見積もって着手すること。新しいカラムを「追加」するのは技術的には簡単 (ALTER TABLE ADD COLUMN) ですが、追加した後にそれを使う側のロジックを揃える部分が本当の作業量です。

別解: 設計時から「将来ニックネームを追加するかもしれない」と予想していれば、最初から display_name のような汎用カラムを作っておく方法もあります。ただし、起きるかわからない変更のために設計を複雑にすると、それはそれで保守コストが上がります。「将来の変更にどこまで備えるか」はトレードオフです。

演習 2: 設計時の判断

あなたが新しい SNS の posts (投稿) テーブルを設計しているとします。次の判断のうち、後で変更するのが最も大変なのはどれだと思いますか? 理由とともに考えてみてください。

投稿本文の最大長を 280 文字 → 1000 文字に増やす
投稿に「カテゴリ」(タグのようなもの) を追加する
主キーの型を INTEGER → BIGINT に変える (約 21 億の上限を超えて扱えるように)
投稿の削除を物理削除 → 論理削除に変更する

解答例

3 (主キー型の変更) が最も大変になる可能性が高いです。理由:

主キーは他のテーブルの外部キーから参照されている可能性が高い (comments.post_id, likes.post_id など) ため、参照している側のテーブルもすべて型を合わせる必要がある
主キーは多くのインデックスに含まれるため、変更にはインデックス再構築が必要で、本番データが大量だと時間がかかる
アプリ側で主キーを扱う型 (TypeScript の number、Python の int) もすべて変更する必要がある

他の選択肢の難しさ:

1 (本文最大長): 単純な ALTER TABLE ALTER COLUMN で済むことが多い。比較的軽い
2 (カテゴリ追加): 新規カラムを追加するだけなら軽いが、多対多にするなら中間テーブルが必要 (第 14 章「多対多」参照)。中規模の作業
4 (論理削除化): deleted_at カラムを追加し、削除クエリと参照クエリを書き換える。中規模の作業

だからこそ: 主キーの型は最初から BIGINT で作っておくのが一般的なベストプラクティスです。INTEGER (約 21 億まで) で間に合うかどうかは将来読みづらく、BIGINT (約 922 京) にしておけば現実的に枯渇しません。ストレージのオーバーヘッドはわずかです。

まとめ

この章で学んだことを整理します。

データベース設計は「建物の基礎」に相当し、運用後の修正は質的に難しい
後から直しにくい 3 つの理由: 「サービスを止められない」「データ移行コスト」「影響範囲の広さ」
設計時の小さな判断 (主キー型 / 文字数 / タイムゾーン / 削除方式) が将来の運用負荷に大きく効く
AI 時代でもデータ構造の設計力は変わらず重要 (むしろクラウドコストとして可視化される)

次章では、データベースの基本機能 (CRUD + ACID) を実際の SQL を見ながら学びます。

次の章

第 4 章 CRUD と ACID

この章で学ぶこと​

データベース設計は「建物の基礎」​

設計ミスが後から直しにくい質的理由​

1. 運用中のサービスを止められない​

2. データ移行のコスト​

3. 影響範囲が広い​

設計時の判断が将来何に影響するか​

データ設計スキルは AI 時代でも価値を持つ​

1. AI の燃料はデータ​

2. クラウド DB を使っても設計は変わらない​

3. すべてのエンジニアの共通言語​

データベース設計ができると何ができるか​

演習​

まとめ​