データベース設計の実践 ― SaaSのスキーマ・マイグレーション・バックアップを正しく整える

SaaSが扱う最も大切な資産は，コードでもサーバーでもなくデータだ．ユーザーが蓄積したデータこそがサービスの価値であり，それを失えば顧客は二度と戻ってこない．だからこそ，そのデータを保持するデータベースの設計と運用は，SaaSの生命線になる．

ところが，データベース設計は地味で後回しにされがちだ．とりあえず動くテーブルを作り，設計の原則もバックアップも考えずに走り出す── そして運用が始まってから，『構造を変えられない』『データが壊れた』『消えた』という取り返しのつかない事態に直面する．

この記事は，マルチテナント設計を終え，本格的にデータを扱う個人開発者に向けて書いている．スキーマ設計の基本，適切なデータ型，リレーションとインデックス，安全なマイグレーション，そして命綱となるバックアップまで，特定のDB製品に依らず実践的な勘所を解説する．

扱う範囲は，設計の重要性 → 正規化とスキーマ → データ型の選び方 → リレーション → インデックス → マイグレーション → バックアップ戦略 → 復旧の備え → パフォーマンス → よくある失敗，だ．読み終えたとき，あなたはデータを失わず，長く育てられるDB設計の指針を得ている．

なぜ「最初のDB設計」が決定的に重要なのか

データベースのスキーマ(テーブルの構造)は，アプリケーションの中で最も変更が難しい部分だ．コードはいつでも書き換えられるが，すでに大量のデータが入ったテーブルの構造を変えるのは，慎重な手順を踏まないとデータ破損を招く．だから最初の設計が，後々まで効いてくる．

とくにSaaSは，何年も運用しながらデータが増え続ける．設計が雑だと，データが増えるほどパフォーマンスが落ち，変更が怖くなり，バグの温床になる．逆に，最初に筋の良い設計をしておけば，機能追加もスケールも楽になる．

そして最も恐ろしいのがデータの喪失だ．サーバー障害，操作ミス，攻撃── データが消える原因はいくらでもある．バックアップを取っていなければ，その瞬間に事業は終わる．これは大げさではなく，現実に起きていることだ．

本記事のメッセージは2つ．『最初に筋の良いスキーマを設計する』『何があってもデータを失わない備えをする』．この2つを押さえれば，データという最重要資産を守りながら，長く運用できるSaaSの土台が完成する．

スキーマ設計の基本 ― 正規化で重複をなくす

スキーマ設計の出発点は正規化だ．正規化とは，データの重複をなくし，一つの事実を一か所だけに保存するようにテーブルを整理する考え方を指す．重複があると，更新漏れで矛盾したデータが生まれ，バグの温床になる．

たとえば，注文のたびに顧客の住所を毎回コピーして保存していると，顧客が引っ越したときに過去の全注文を直す羽目になる．代わりに顧客テーブルを分け，注文テーブルからは顧客IDで参照すれば，住所は一か所を直すだけで済む．これが正規化の威力だ．

個人開発では，まず『一つの事実は一か所に』という原則を守ることを意識すれば十分だ．厳密な正規化理論を完璧に適用する必要はないが，明らかな重複を作らないだけで，データの整合性は大きく保たれる．

ただし，正規化を突き詰めすぎると，データ取得時に多数のテーブルを結合する必要が出て，かえって複雑・低速になることもある．実務では『基本は正規化し，性能上必要な箇所だけあえて重複を許す(非正規化)』というバランスを取る．まずは正規化を基本に据えよう．

テーブルは「モノ」ごとに分ける

設計に迷ったら，現実世界の『モノ(実体)』ごとにテーブルを分けると考えると整理しやすい．ユーザー，組織，注文，商品── それぞれが独立した『モノ』であり，1テーブルになる．そして『モノ』同士の関係を，IDで結びつけていく．

この『モノ単位で考える』発想は，複雑なデータ構造を素直に表現する助けになる．1つのテーブルに何でも詰め込むのではなく，意味のまとまりごとに分け，関係で結ぶ．これがリレーショナルDBの基本姿勢だ．

マルチテナントのテナントIDを忘れない

前回学んだ通り，SaaSではテナントに属するすべてのテーブルにテナントIDを持たせる．スキーマ設計の段階で，これを各テーブルに組み込むことを忘れてはならない．後から全テーブルに追加するのは大きな手間になる．

テナントID列には，後述するインデックスも付けておきたい．テナントで絞り込む検索が頻繁に発生するため，ここにインデックスがあるかどうかで性能が大きく変わる．設計時に織り込んでおこう．

データ型の選び方 ― 適切な型が品質を守る

各カラム(列)に適切なデータ型を割り当てることは，データ品質の基本だ．数値は数値型，日時は日時型，真偽値は真偽型を使う．何でも文字列で保存すると，計算も比較も並び替えも正しくできず，後で必ず苦労する．

とくに日時の扱いは要注意だ．日時は専用の型で保存し，タイムゾーンを意識して統一(通常はUTCで保存し，表示時に変換)する．文字列で日付を保存すると，並び替えや期間検索が破綻し，SaaSの予約や履歴機能が崩れる原因になる．

金額の扱いも慎重に．小数の誤差が許されない金額は，浮動小数点ではなく整数(最小単位で保存)や専用の数値型を使う．課金にまつわる計算で1円のズレも許されないことを考えれば，ここでの型選択がいかに重要かが分かる．

状態や区分(『下書き/公開/削除済み』など)は，自由な文字列ではなく決められた値に限定する(列挙型や参照テーブル)．これにより，表記ゆれやタイプミスによる不正な値の混入を防げる．適切な型は，それ自体がデータの番人になってくれる．

IDの設計を最初に決める

各レコードを一意に識別する主キー(ID)の方式も，最初に決めておきたい．連番の整数か，推測されにくいランダムなID(UUID等)か．URLにIDが出るSaaSでは，連番だと『次の番号で他人のデータを推測される』リスクがあり，ランダムIDが安全なこともある．

どちらにも一長一短があるが，重要なのは『途中で変えにくいので最初に決める』ことだ．前回のマルチテナントの『他人のデータが見える』事故とも絡むため，IDの推測しやすさはセキュリティ観点でも検討しておこう．

NULLを許すかを意識する

各カラムが『空(NULL)を許すか』も，設計時に決めるべき重要事項だ．必須の項目はNULLを禁止し，任意の項目だけ許す．これを曖昧にすると，『あるはずのデータが無い』状態が紛れ込み，表示やロジックのバグを生む．

『必須なのに空が入りうる』設計は，後々のバグの温床になる．データベースの制約として必須・任意を明示しておけば，不正なデータがそもそも入らないよう，DB自身が守ってくれる．

リレーション ― テーブル同士を正しく結ぶ

正規化で分けたテーブル同士は，リレーション(関係)で結びつける．注文は顧客に属し，商品明細は注文に属する── このような『属する』関係を，外部キー(参照先のID)で表現する．これがリレーショナルDBの中核だ．

関係には『1対多(1人の顧客が多数の注文を持つ)』『多対多(1ユーザーが複数組織に属し，組織も複数ユーザーを持つ)』などの種類がある．前回のマルチテナントで触れた組織とユーザーの関係は，まさにこの多対多であり，間に中間テーブルを置いて表現する．

リレーションを正しく設計すると，データの整合性をDB自身が守ってくれる．たとえば外部キー制約を付ければ，存在しない顧客IDを持つ注文が作られるのを防げる．アプリのバグでおかしなデータが入るのを，DBレベルで食い止められるのだ．

外部キー制約には，参照先が消えたときの挙動(連動して消すか，消させないか)も設定できる．たとえば『顧客を削除したら，その注文も連動して扱う』といったルールをDBに持たせられる．前回のテナント削除の設計とも関わる重要なポイントだ．

「中間テーブル」で多対多を表す

多対多の関係は，2つのテーブルのIDを組み合わせて持つ『中間テーブル』で表現する．ユーザーと組織なら，『ユーザーID・組織IDの組』を records する所属テーブルを作る．これにより，1人が複数組織に，1組織が複数人に，自在に対応できる．

中間テーブルには，関係そのものに付随する情報(その組織でのユーザーの役割など)も持たせられる．前回の権限管理とつなげると，『どのユーザーが，どの組織で，どんな役割か』を，この中間テーブルで一元的に表現できる．

削除は「論理削除」も検討する

データを物理的に消す(行ごと削除)のではなく，『削除フラグ』を立てて見えなくする『論理削除』も有力な手法だ．誤削除からの復旧や，削除済みデータの監査ができ，関連データの整合性も保ちやすい．

ただし論理削除は，全クエリで『削除済みを除外する』必要が生じ，データも溜まり続ける．前回のテナントのライフサイクルと同様，何を論理削除し，いつ本当に物理削除するかの方針を決めておくとよい．

インデックス ― 検索を速くする要

データが増えてくると，検索の速度が問題になる．その切り札がインデックスだ．インデックスは本の索引のようなもので，特定のカラムでの検索を劇的に速くする．これが無いと，DBは毎回全データを総なめし，遅くなる．

インデックスを張るべき代表は，頻繁に検索条件や結合に使われるカラムだ．SaaSでは，テナントID，ユーザーID，外部キー，よく絞り込む状態カラムなどが筆頭になる．とくに前述のテナントID列へのインデックスは，マルチテナントSaaSの性能の要だ．

ただし，インデックスは万能ではない．張るほど書き込み(挿入・更新)は遅くなり，容量も食う．やみくもに全カラムに張るのは逆効果だ．『よく検索に使うカラムに，必要な分だけ』というバランスが，適切なインデックス設計になる．

実務では，まず素直に設計し，実際に遅いクエリが見つかったらインデックスを追加するという順序でよい．最初から完璧なインデックス設計を狙うより，運用しながら計測して，ボトルネックに対処する方が現実的だ．性能計測は第35回で詳しく扱う．

複合インデックスとカバリング

複数カラムをまとめて検索する場合は，それらをまとめた『複合インデックス』が効く．たとえば『テナントIDと状態で絞り込む』検索が多いなら，両方を含む複合インデックスを張ると，単一インデックスより高速になる．カラムの順序も性能に影響する．

ここは奥が深い領域だが，個人開発の初期は『よく一緒に使う条件をまとめる』程度の理解で十分だ．深掘りが必要になるのは，データが相当増えてからになる．まずは基本のインデックスを押さえよう．

ユニーク制約で重複を防ぐ

インデックスの一種であるユニーク制約は，特定のカラムの値が重複しないことをDBに保証させる．たとえば『同じメールアドレスで2つのアカウントを作らせない』を，DBレベルで強制できる．アプリのチェックだけに頼るより確実だ．

前回の認証で触れた『同じメールで二重アカウント』の防止も，このユニーク制約が土台になる．データの一意性は，アプリのロジックではなくDBの制約で守るのが，最も堅牢な方法だ．

マイグレーション ― スキーマを安全に変更する

サービスを育てていけば，必ずスキーマの変更(カラム追加，テーブル追加など)が必要になる．このとき，本番DBを直接手で変更するのは厳禁だ．手順が記録されず，再現できず，ミスでデータを壊す．代わりに使うのがマイグレーションだ．

マイグレーションとは，スキーマの変更内容をコードとして記録し，順番に適用していく仕組みだ．多くのフレームワークが標準で備えている．これにより，変更履歴が残り，別環境でも同じ変更を再現でき，必要なら巻き戻しもできる．

個人開発でも，スキーマ変更は最初からマイグレーションで管理するべきだ．『1人だから手で変えればいい』は，再現性と安全性を捨てる危険な発想．最初からマイグレーションに乗せておけば，開発環境と本番環境のズレも防げる．

マイグレーションの考え方(擬似的な例)

# 変更を『前進(up)』と『巻き戻し(down)』のペアで記録する
up:   ALTER TABLE users ADD COLUMN plan TEXT NOT NULL DEFAULT 'free';
down: ALTER TABLE users DROP COLUMN plan;
# これをファイルとして残し，順番に適用・取り消しできるようにする

重要なのは，本番への適用は慎重に，そして必ずバックアップを取ってから行うことだ．大量データのあるテーブルへの変更は時間がかかったり，ロックがかかったりする．テスト環境で試し，影響を確認してから本番に適用する習慣をつけよう．

後方互換を保って段階的に変える

稼働中のサービスでスキーマを変えるときは，古いコードと新しいスキーマが一時的に共存できるよう，段階的に進めるのが安全だ．たとえばカラム削除なら，まずコードで使うのをやめ，十分経ってから実際に削除する，という順序を踏む．

一気に『コードもスキーマも同時に変更』すると，デプロイの僅かな時間差で不整合が起き，エラーになることがある．急がば回れで，互換性を保ちながら少しずつ変えるのが，無停止運用のコツだ．

マイグレーションもバージョン管理する

マイグレーションファイルは，コードと一緒にGitでバージョン管理する．これにより，『どのコードのとき，DBがどの構造だったか』が完全に追跡できる．第6回で触れたGit管理の恩恵が，ここでも効いてくる．

チームでなくても，過去の自分との連携のためにこれは重要だ．数か月後に『なぜこの構造にしたのか』を思い出すためにも，変更の履歴が残っていることの価値は大きい．

バックアップ戦略 ― これが無ければ全てが無意味

ここからが本記事で最も重要な話だ．どれだけ美しくスキーマを設計しても，バックアップが無ければ，一度の事故で全データが消え，事業が終わる．バックアップは『あったらいい』ではなく『無ければ営業してはいけない』レベルの必須事項だ．

バックアップの基本指針として有名なのが『3-2-1ルール』だ．データのコピーを3つ持ち，2種類の異なる媒体に保存し，うち1つは別の場所(オフサイト)に置く．これにより，サーバーごと失われても，別の場所のコピーから復旧できる．

個人開発でも，最低限『定期的に自動でバックアップを取り，それを本番サーバーとは別の場所に保存する』ことは欠かせない．同じサーバーにだけバックアップを置いても，サーバー自体が飛べば一緒に失われる．別の場所に逃がすことが肝心だ．

とくに見落とされるのが，最後の『復元できるか試す』だ．バックアップは取っているつもりでも，いざというときに壊れていて戻せない，というのは悲劇的によくある．定期的に『実際に別環境へ復元してみる』テストまでやって，初めてバックアップは完成する．

自動化して「忘れない」仕組みに

バックアップは，必ず自動化する．手動では，忙しいときに必ず忘れ，そういうときに限って事故が起きる．サーバーの定期実行(cronやsystemd timer)で，毎日決まった時刻に自動でバックアップを取り，別の場所へ転送する仕組みを組もう．

VPSで運用しているなら，こうした自動バックアップのスクリプトを自分で組める．オブジェクトストレージなどの安価な別保存先に逃がせば，コストも抑えられる．具体的な障害復旧の設計は，第19回でさらに掘り下げる．

「いつ時点に戻せるか」を意識する

バックアップの頻度は，『最悪，いつ時点まで戻ってよいか』から逆算する．1日1回なら，最大1日分の更新が失われうる．それが許容できないサービスなら，より頻繁なバックアップや，変更を逐次記録する仕組みが必要になる．

個人開発のマイクロSaaSなら，まず『毎日1回・別の場所へ・複数世代』を確実に回すことを目標にしよう．完璧を目指す前に，まず『何があっても昨日の状態には戻せる』状態を作ることが，何より大切だ．

復旧の備え ― 事故は起きる前提で

バックアップは『取る』だけでなく『戻せる』ところまでが備えだ．実際に事故が起きたとき，パニックの中で確実に復旧できるかが問われる．そのためには，復旧の手順をあらかじめ決め，できれば文書化しておくことが望ましい．

考えておくべきシナリオは複数ある．『操作ミスでデータを消した』『サーバーが壊れた』『データが破損した』── それぞれで復旧の手順は変わる．すべてに完璧に備える必要はないが，最低限『最新のバックアップから本番を復元する手順』は把握しておきたい．

そして，これらは平時に一度試しておくことが決定的に重要だ．事故が起きてから初めて復旧手順を調べるのでは，焦りでミスを重ね，傷を広げる．一度でも復旧を経験しておけば，いざというとき落ち着いて対処できる．

個人開発では，ここまで手が回らないことも多い．だが，せめて『バックアップが取れていること』と『一度は復元を試したこと』の2点だけは，必ず押さえておこう．この最低限の備えが，最悪の事態からあなたの事業を救う．

操作ミスにこそ備える

実は，サーバー障害より頻繁に起きるのが自分の操作ミスだ．誤って本番データを消す，間違ったマイグレーションを当てる── 個人開発では『自分』が最大のリスク要因になりうる．だからこそ，戻せる備えが効く．

本番に対する危険な操作の前には，必ずバックアップを取る癖をつけよう．前述のマイグレーションも，本番適用前のバックアップが鉄則だ．『戻せる』という安心感が，思い切った改善も可能にしてくれる．

パフォーマンス ― 遅くなる前の心構え

データが増えると，クエリが遅くなることがある．だが個人開発の初期から，過度にパフォーマンスを心配して設計を複雑にする必要はない．まず素直で正しい設計をし，遅さが実際に問題になってから対処するのが基本姿勢だ．

とはいえ，最低限の心構えはある．『よく検索する条件にはインデックスを張る』『一覧表示は件数を区切る(ページング)』『無駄に大量のデータを一度に取得しない』といった基本を守るだけで，多くの性能問題は未然に防げる．

そして，遅いクエリを特定する手段(実行計画の確認やログ)を知っておくと，いざというとき役立つ．『どのクエリが，なぜ遅いか』を計測して，その箇所だけ直す．勘で闇雲に最適化するのではなく，計測に基づいて対処するのが正攻法だ．

繰り返すが，性能対策は『大成功してデータが膨大になってから』が本番だ．それは喜ばしい問題であり，その頃には対処する知見も資金もある．今は，正しい設計とインデックスの基本を押さえ，過剰な早すぎる最適化は避けよう．詳しくは第12回・第35回で扱う．

N+1問題に気をつける

個人開発で起きがちな性能の罠が『N+1問題』だ．一覧を表示するとき，各行ごとに関連データを1件ずつ取得してしまい，表示件数の分だけクエリが飛んで激遅になる現象を指す．一覧表示で急に遅くなったら，まずこれを疑う．

対策は，関連データをまとめて一度に取得する(イーガーロード等)ことだ．多くのORMにこの機能がある．N+1は知らないとハマり，知っていれば簡単に避けられる典型的な落とし穴なので，名前だけでも覚えておこう．

データベースでやりがちな失敗

最後に，個人開発のDB設計・運用でありがちな失敗を確認しよう．いずれも，データという最重要資産を危険にさらすものばかりだ．

• バックアップを取っていない：一度の事故で全データと事業を失う(最悪)
• 本番DBを手で直接いじる：再現性がなく，ミスでデータを壊す
• 何でも文字列で保存：計算・比較・並び替えが破綻する
• テナントIDやインデックスを後回し：後から追加が大変・性能劣化
• 復元を試したことがない：バックアップがあっても戻せず無意味

共通する最大の教訓は，改めて『バックアップを自動で取り，別の場所に保存し，復元を試しておく』ことだ．設計の巧拙以前に，データを失わない備えがすべての前提になる．ここだけは，何があっても妥協してはいけない．

公開前にバックアップ体制を確認する

サービスを公開する前に，『バックアップが自動で取れているか』『別の場所に保存されているか』『一度復元できたか』を必ず確認しよう．ユーザーのデータを預かるということは，それを守る責任を負うということだ．

この確認は，認証やマルチテナントの安全確認と並ぶ，公開前の必須チェックだ．地味だが，ここを固めておくことが，長く信頼されるSaaSの土台になる．データを守れない者に，SaaSを名乗る資格はない．

補論 ― データを守る土台は「自分で握る」

データベースの設計をどれだけ磨いても，それを動かすサーバーと，バックアップを逃がす先がなければ，データは守れない．そして個人開発では，この『データを守る土台』を自分でコントロールできることが，安心につながる．

高速NVMe・50種類以上のOSテンプレートに対応した国内VPS─シン・VPS─のような高性能なVPSなら，データベースを自前で安定運用でき，定期バックアップの自動化スクリプトも自由に組める．バックアップの保存先を別のストレージへ逃がす設定も，自分の管理下で柔軟に行える．データという最重要資産を，他人任せにせず自分の手で守れるのは，大きな強みだ．そして，そのサービスの顔となる独自ドメインは取り扱い400種類以上のドメイン取得サービス─ムームードメイン─で取得し，長く付き合うサービスの『住所』として最初に確保しておこう．

『筋の良いスキーマを，自分で守れる土台の上で運用し，バックアップで絶対に失わない』── これがデータを扱うSaaSの正解だ．データの土台が固まったら，次はそこにお金の流れを通す番だ．次回は『課金システムの実装』を解説する．

よくある質問(FAQ)

Q1．正規化はどこまで厳密にやるべきですか？

個人開発では『一つの事実は一か所に』という原則を守れば十分です．厳密な正規化理論を完璧に適用する必要はなく，明らかな重複を作らないだけでデータの整合性は大きく保たれます．ただし性能上必要な箇所だけは，あえて重複を許す（非正規化）バランスも実務では使います．

Q2．主キー（ID）は連番とランダム，どちらがいい？

一長一短です．連番は扱いやすいですが，URLにIDが出るSaaSでは『次の番号で他人のデータを推測される』リスクがあり，その場合はランダムなID（UUID等）が安全です．どちらでも，途中で変えにくいので最初に決めること，そして他人のデータが見えないよう認可チェックを徹底することが重要です．

Q3．日付や金額はどう保存すればいい？

日付は文字列でなく日時型で，タイムゾーンを統一して（通常UTCで保存し表示時に変換）扱います．金額は誤差の出る浮動小数点を避け，整数（最小単位で保存）や専用の数値型を使います．何でも文字列で保存すると計算・比較・並び替えが破綻するので，適切な型を割り当ててください．

Q4．インデックスはどこに張ればいいですか？

頻繁に検索条件や結合に使うカラム（テナントID・ユーザーID・外部キー・よく絞り込む状態など）に張ります．とくにマルチテナントのテナントID列は性能の要です．ただし張るほど書き込みは遅くなるので，まず素直に設計し，実際に遅いクエリが見つかってから追加するのが現実的です．

Q5．スキーマを変更したいときの安全な方法は？

本番DBを手で直接変えず，必ずマイグレーション（変更をコードとして記録し順番に適用する仕組み）を使います．多くのフレームワークが標準で備えています．本番適用前には必ずバックアップを取り，テスト環境で試してから．稼働中の変更は後方互換を保ちつつ段階的に進めると安全です．

Q6．バックアップはどう取ればいいですか？

最低限『毎日など定期的に自動で取り，本番サーバーとは別の場所に，複数世代を保存する』ことです（3-2-1ルールが目安）．手動は必ず忘れるので自動化が必須．同じサーバーにだけ置くとサーバー巻き添えで失うため，別の場所へ逃がすのが肝心です．

Q7．バックアップを取っていれば安心ですか？

取るだけでは不十分で，『実際に復元できるか』を試して初めて完成です．取れているつもりでも壊れていて戻せない，というのは悲劇的によくあります．定期的に別環境へ復元するテストを行い，復旧手順も平時に一度経験しておきましょう．

Q8．一覧表示が急に遅くなりました．原因は？

『N+1問題』の可能性が高いです．一覧の各行ごとに関連データを1件ずつ取得し，件数の分だけクエリが飛んで激遅になる現象です．対策は関連データをまとめて一度に取得すること（イーガーロード等）．多くのORMにこの機能があります．ページングで表示件数を区切ることも有効です．

まとめ ― 筋の良い設計と，絶対に失わない備え

データベースはSaaSの最重要資産であるデータを預かる土台だ．最初に筋の良いスキーマを設計し，適切な型・リレーション・インデックスで整え，マイグレーションで安全に育てる── これが，長く運用できるSaaSの基礎になる．

そして何より，『バックアップを自動で取り，別の場所に保存し，復元を試しておく』こと．設計の巧拙以前に，データを失わない備えがすべての前提だ．ここだけは，何があっても妥協してはいけない．

正規化・型・リレーション・インデックス・マイグレーションは，過剰に作り込まず，基本を押さえて運用しながら育てればよい．だがバックアップだけは，公開前に必ず固める．データを守れることが，顧客の信頼を守ることに直結する．

データの土台が固まったら，いよいよそこにお金の流れを通す番だ．次回は，サブスクと従量課金を安全に実装する『課金システムの実装』を，決済プラットフォームの活用を中心に解説する．