前回の続きと、この最終回の役割
前回のL-09では、制約とトランザクションで「壊れたデータを作らせない守り」を学びました。ここまでで、分けて保存し、キーで結び、取り出し、安全に変える、という設計と操作は一通り揃いました。最終回で扱うのは、作った後に運用していくための3つの備えです。速さの手当て、構造変更の管理、そして障害からの復旧。この3点を分けて理解することが、この講義の目標です。
このスライドのポイント
- 前回L-09: 制約とトランザクションで「壊れたデータを作らせない守り」を学んだ
- ここまでで、分けて保存し・キーで結び・取り出し・安全に変える、という設計と操作は一通り揃った
- この講義: 作った後に「運用していく」ための3つの備えを扱う
- 速さの手当て／構造変更の管理／障害からの復旧、を分けて理解する
3つの定義
定義から始めます。インデックスとは、検索を速くする索引です。本の巻末の索引と同じで、よく検索する列に張っておくと、目的の行を素早く見つけられます。マイグレーションとは、テーブルの構造の変更を、履歴の残る手順書として管理し適用する仕組みです。L-03で予告した「列を増やす」は、これで行います。バックアップとは、データの複製を別の場所に取り、障害時に復元できるようにすることで、A-09やL-08で繰り返してきた「バックアップ確認」の実体です。
このスライドのポイント
- インデックス＝検索を速くする索引（本の巻末の索引と同じ。よく検索する列に張る。E-10の計算量の改善手段）
- マイグレーション＝テーブルの構造の変更を、履歴の残る手順書として管理・適用する仕組み（L-03で予告した「列を増やす」はこれで行う）
- バックアップ＝データの複製を別の場所に取り、障害時に復元できるようにすること（A-09・L-08で言い続けた「バックアップ確認」の実体）
無いと何が起きるか
この3つを知らないと、運用の3大事故をそのまま踏み抜きます。データが増えて一覧の表示が遅い、これはインデックスが無い状態です。本番のテーブルを手で直したら壊れた、これはマイグレーションを無視した状態です。消したデータが戻らない、これはバックアップが無い状態です。どれも、作っているときには見えにくく、運用が始まってから牙をむきます。
このスライドのポイント
- 運用の3大事故は、この3つの不在にそのまま対応する
- インデックス無し → データが増えて一覧の表示が遅い
- マイグレーション無視 → 本番のテーブルを手で直したら壊れた
- バックアップ無し → 消したデータが戻らない
- どれも作っている間は見えにくく、運用が始まってから牙をむく
目的別の整理
構造として押さえてほしいのは、3つの役割がまったく違うことです。インデックスの目的は速さ、マイグレーションの目的は構造変更の管理、バックアップの目的は復旧です。無いと起きることも、遅くなる・壊れる・戻せない、と別々です。使うタイミングも違います。だからこそ、ひとまとめにせず、目的別の表として整理しておくと、どれを使う場面かで迷いません。
このスライドのポイント
- 3つは役割がまったく違う。ひとまとめにしない
具体例で流れを見る
具体例で流れを見ます。経費が1万件に増え、user_idでの検索が遅くなったとします。ここはインデックスを張れば速くなります。E-10で学んだ、件数が増えたときの手当ての実例です。一方、経費に備考の列を追加したいときは、手作業では直しません。マイグレーションのファイルを1つ書き、開発環境から本番環境まで、同じ手順で順に適用します。速さの問題と構造変更の問題は、打ち手がこのように分かれます。
このスライドのポイント
- 速さの問題: 経費が1万件に増え、user_id検索が遅い → インデックスを張って解決（E-10「増えたときの手当て」の実例）
- 構造変更の問題: 経費に備考の列を追加したい → 手作業で直さず、マイグレーションのファイルを書く
- そのファイルを開発環境から本番環境まで（B-06）、同じ手順で順に適用する
- 打ち手が問題の種類ごとに分かれる
技術サンプル: CREATE INDEX とマイグレーション
サンプルを見ます。1行目のCREATE INDEXが、user_id列に索引を張る指示で、これは即効性のある手当てです。その下は、マイグレーションの考え方を疑似的に書いたものです。変更を1つの履歴ファイルに書き、順番を付けて保存し、各環境へ同じ手順で適用していきます。インデックスが即効なら、マイグレーションは規律だと考えてください。なお、バックアップはDBMSやクラウドの機能で定期的に取りますが、その詳細はカテゴリSで扱います。
このスライドのポイント
- 種別: sql
- 目的: 検索を速くする索引の作成と、構造変更を履歴で管理する考え方を読む
- サンプル本体:
混同しやすい概念
混同しやすいのが、マイグレーションとバックアップです。どちらも変更に備えるものですが、対象が違います。マイグレーションが備えるのは構造の変更、つまりテーブルの形です。バックアップが備えるのは中身、つまりデータそのものです。形の変更履歴を残すことと、中身の複製を取ることは、別々に必要になります。
このスライドのポイント
- マイグレーション と バックアップ は、どちらも「変更に備える」が対象が違う
バイブコーディングでの確認点
バイブコーディングでの確認点は、公開前の3問です。1つ目、表示の遅い画面はないか、あればその検索列にインデックスが張られているか。2つ目、テーブルの構造変更はマイグレーション経由で管理されているか。3つ目、バックアップは自動で取れていて、復元の手順を実際に試したか。取れているだけでは不十分で、戻せることを確かめて初めて安心できる、というのが実務の教訓です。
このスライドのポイント
- 公開前チェック3問:
一問一答とまとめ
一問一答です。検索を速くする仕組みは何でしょうか。……答えはインデックスです。30秒まとめです。インデックスは速さ、マイグレーションは構造変更の管理、バックアップは復旧。3つは目的が違い、どれも省けません。これでカテゴリLは修了です。保存の設計から、守り・速さ・復旧まで揃い、画面から保存までを扱うStep 3を完走しました。次回からはカテゴリM、作る前の企画と要件定義へ進みます。関連資料は「業務アプリDB設計パターン50」「バックアップと復旧入門」「アプリ運用チェックリスト」です。
このスライドのポイント
- 一問一答: 「検索を速くする仕組みは？」→ 答: インデックス
- 30秒まとめ: インデックス=速さ／マイグレーション=構造変更の管理／バックアップ=復旧。目的が違い、どれも省けない
- カテゴリL修了。保存の設計から、守り・速さ・復旧まで揃った。Step 3（画面から保存まで）完走
- 次回: カテゴリM、作る前の企画と要件定義へ
- 関連資料: 「業務アプリDB設計パターン50」「バックアップと復旧入門」「アプリ運用チェックリスト」
