データベースは、アプリの画面ではなく「何を一件として記録するか」から設計します。
製品名を決める前に、データの所有者、更新の単位、同時更新、保存期間を明らかにしてください。
この四点が固まると、端末内DB、リレーショナルDB、BaaSの向き不向きを比べられます。
アプリ開発の目的に合う相談先は、外注と学習を目的別に分けた相談ガイドにまとめています。
| 保存先 | 得意な使い方 | 先に決めること |
|---|---|---|
| 端末内DB | オフライン利用、キャッシュ | 同期、端末交換、暗号化 |
| リレーショナルDB | 関係を保つ業務データ | 表、キー、制約、トランザクション |
| BaaSの管理DB | 認証とAPIを組み合わせた試作 | アクセス権、上限、データ出力 |
保存先を三つの用途で使い分ける
端末内DBは、通信できない状態でも読み書きしたいデータに向きます。
ただし、別端末との同期を始めると、どちらの更新を残すかという新しい規則が必要でしょう。
リレーショナルDBは、会員、注文、注文明細のように、データ同士の関係と制約を保つ業務に適します。
PostgreSQLのデータ定義資料は、表、列、制約、権限などを設計要素として扱っています。
BaaSは、DBだけでなく認証、API、ストレージを合わせたい場合の候補です。
Postgresを中心に複数の機能がどう接続されるかは、Supabase Architectureで確認してください。
| 判断軸 | 端末内DB | サーバーの関係DB | BaaS |
|---|---|---|---|
| オフライン | 強い | 通信が必要 | 同期設計が必要 |
| 複数人の共有 | 追加実装が必要 | 得意 | 標準APIを使いやすい |
| 運用責任 | アプリ開発側 | DB運用側 | 提供者と開発側で分担 |
画面から離れてデータモデルを作る
一画面に見える情報をそのまま一表に入れると、同じ会員名や商品名が複数の場所へ重複します。
会員、注文、商品といった識別できる対象を分け、IDで関係を表します。
最初の設計は次の五段階で進められます。
- 記録対象を名詞で並べる
- それぞれを一意に識別するIDを決める
- 必須、重複不可、削除可否の制約を決める
- 登録、変更、削除の業務ルールをテストにする
- 現実的な件数で検索と更新の速度を測る
日時、金額、状態は文字列でひとまとめにせず、検索と集計に使える型を選びます。
「削除する」と「非表示にする」も別の操作として定義してください。
注文データの行数を数える計算例
次の数字は容量を見積もるための仮定です。
会員1,000人が年間に平均12回注文し、一注文あたり平均3商品を含むとします。
注文テーブルは1,000人×12回で1万2,000行になるでしょう。
注文明細テーブルは1万2,000注文×3商品で3万6,000行になります。
| テーブル | 計算 | 年間行数 |
|---|---|---|
| 会員 | 1,000人 | 1,000行 |
| 注文 | 1,000人×12回 | 12,000行 |
| 注文明細 | 12,000注文×3商品 | 36,000行 |
画面の件数ではなく、関連テーブルの行数と増え方まで出すと、テストデータの規模を決められます。
保存容量は列の大きさ、履歴、インデックス、バックアップも含めて別に試算します。
インデックスと権限を必要な場所に絞る
インデックスは検索を高速化できますが、更新時の処理と保存領域が増えるでしょう。
PostgreSQLのインデックス資料でも、索引はテーブル全体の走査を避けられる一方、システム全体に負担を加えることが説明されています。
「よく検索条件に使う」「結果を少数へ絞れる」列から検討し、実際のクエリで効果を測ります。
すべての列へ機械的に追加しないことが重要です。
認証済みの利用者でも、他人のデータまで読んでよいわけではありません。
Supabase Authのように、本人確認とデータアクセス制御を別の責任として組み合わせます。
アプリ開発のデータベースでよくある質問
小さなアプリでもサーバーのDBは必要ですか？
データを一台の端末だけで使い、共有や復元を要求しないなら端末内DBだけで完結できる場合があります。
複数端末の同期、管理者の更新、バックアップが必要になった時点でサーバー側を検討します。
Supabaseはデータベースそのものですか？
SupabaseはPostgresを中心にしていますが、認証、自動生成API、ストレージなども組み合わせたプラットフォームです。
具体的な構成要素は公式アーキテクチャ資料で確認できます。
インデックスは多いほど速くなりますか？
検索に有効な場合がある一方、更新処理と保存領域の負担が増えます。
PostgreSQL公式の説明にも索引の利点と追加負担が示されているため、実際のクエリを測定して追加します。
データの単位と増え方を決めてからDBを選ぶ
データベース設計の出発点は、サービスの人気ではなく業務上の記録単位です。
テスト時に数件を保存できるだけでなく、公開後の行数、権限、削除、復元まで説明できる設計を目指します。
- 端末内DBとサーバーDBを分ける条件は共有と同期の要否
- 関係DBの基礎は表、ID、制約、更新ルールの組み合わせ
- 容量試算の入力は画面数ではなく関連する全テーブルの行数
- インデックスの利点は検索速度であり対価は更新と保存の負担
保存単位が固まった後は、アプリ用サーバーの費用と運用負担を照合し、DB以外の監視と復旧も同じ構成に入れてください。
