📑 この章の目次
title: データベース適材適所 icon: 🗄️ card_desc: データを保存する道具の選び方 — RDB/NoSQL・SQLite vs PostgreSQL・何で選ぶかの判断軸 slug: 07-database
07 データベース適材適所 — SQLite・PostgreSQL 等、何で選ぶかの判断軸
「データベース」と一口に言っても、目的によって最適な道具は違います。小さなツールには SQLite、大規模サービスには PostgreSQL。この章では、「何で選ぶか」の判断軸を根本から理解します。
一言でいうと
データベースは、アプリが扱うデータを保存・検索・更新・削除する仕組みです。しかし「1つの万能なデータベース」は存在しません。データの規模・同時書き込みの量・データの形・運用コストによって、最適な道具が変わります。この章の核心は、「どの場面でどれを選ぶか」の判断軸を持つことです。
1. なぜ「データベースの選び方」があるのか
まず、そもそもなぜデータベースが必要か。アプリのデータをただのテキストファイルに保存してはいけないのでしょうか。
テキストファイルでの保存は、小規模なら動きます。しかし：
- 「ユーザーID=123 の注文だけ、新しい順で20件」のような検索が遅くなる
- 2人が同時に書き込むとデータが壊れる（同時書き込みの問題）
- 「金額×個数=合計」のような整合性を保つ仕組みがない
これらを解決するのがデータベースです。データの保存・検索・整合性を、安全かつ高速に担う専用の仕組みです。
💡 SQL（エスキューエル／Structured Query Language）は、RDB（後述）を操作するための共通言語です。「このデータを取得して」「このデータを更新して」を、データベースの種類を問わずほぼ共通の文法で書けます。
なぜ「選ぶ」必要があるのか
ここが重要です。すべての場面で最適な「1つのデータベース」はありません。
- 小さなツールに、大規模向けの重いデータベースを導入すると、運用コストで疲弊します
- 大規模サービスに、小規模向けのデータベースを使うと、同時書き込みで詰まります
- 形が決まったデータと形がころころ変わるデータでは、向く道具が違います
つまり**「適材適所」**——目的に応じて最適な道具を選ぶ、という発想そのものが、この章のテーマです。
2. データベースの2大分類 —— RDB と NoSQL
データベースは大きく2つに分かれます。
RDB（リレーショナルデータベース）
RDB（アールディービー／Relational Database／リレーショナルデータベース）は、データを**表（テーブル）**で管理する方式です。Excelのシートのように、**行（レコード）と列（カラム）**でデータを整理します。
- あらかじめ列の形（スキーマ）を決めてからデータを入れる
- SQL で操作する
- 表と表を**関連（リレーション）**づけられる（「注文」表と「ユーザー」表を紐づける等）
- データの整合性を保つ仕組み（トランザクション・後述）が強力
NoSQL（非リレーショナル）
NoSQL（ノーエスキューエル／「SQLでない」の意）は、表以外の形でデータを扱う方式の総称です。「事前に形を決めなくてよい・柔軟」（形がころころ変わる非構造化データ・半構造化データ向き）反面、厳密な整合性は RDB ほど強くないことが多いです。
代表的な種類:
| 種類 | 何を保存するか | 代表例 |
|---|---|---|
| ドキュメント型 | JSON のような柔軟なデータ（形が変わる） | MongoDB（モンゴディービー） |
| キー・バリュー型 | 「鍵」に対する「値」の高速な取得 | Redis（レディース） |
💡 現実の多くのサービスは両方を組み合わせて使います。メインデータは RDB で整合性を保ちつつ、一時キャッシュやアクセスカウント等の「高速に読み書きしたい」部分は Redis のような NoSQL で補う、といった使い分けです（→ 第9章 キャッシュ）。
3. 🔑 RDB の中の適材適所 —— SQLite vs PostgreSQL
ここが本章の核心の1つ目です。RDB の中でも、規模によって選ぶ道具が変わります。代表的な2つを比較します。
SQLite —— 「ファイル1つ」の軽量版
SQLite（エスキューライト）は、データベース全体が1つのファイルに収まる、極めて軽量な RDB です。
- サーバーが不要（アプリに組み込んで使える）
- 導入が圧倒的に簡単（ファイルを置くだけ）
- ただし同時書き込みに弱い（大勢がいっせいに書き込む用途には向かない）
PostgreSQL / MySQL —— サーバー型の本格版
PostgreSQL（ポストグレス・キューエル／通称「ポストグレス」）や MySQL（マイエスキューエル）は、専用のサーバーとして動かす本格的な RDB です。
- 同時書き込みに強い（大勢が同時に書き込める）
- 大規模データの高速な検索や複雑な集計が得意
- ただし運用コストがかかる（サーバーを立て・監視・バックアップ等の管理が要る）
比較表
| SQLite | PostgreSQL / MySQL | |
|---|---|---|
| 形態 | ファイル1つ（サーバー不要） | サーバー型（専用プロセス） |
| 導入 | 圧倒的に簡単 | サーバー構築・管理が要る |
| 同時書き込み | 弱い（ロックが発生しやすい） | 強い（多数の同時書き込み可） |
| 向く場面 | 個人ツール・プロトタイプ・組込・テスト | 本番のWebサービス・大規模 |
| 運用コスト | ほぼゼロ | 監視・バックアップ等の手間あり |
例えていうと: 手帳と金庫
- SQLiteは「自分用の手帳」。すぐ開けて・すぐ書けて便利ですが、複数人が同時に同じページに書き込むとぶつかります。
- PostgreSQL/MySQLは「職場の金庫（共有金庫）」。管理人（サーバー）がいて、複数人が順番に整理して出入れできますが、管理人を雇う（運用する）手間がかかります。
💡 判断の目安: 「同時に大勢が書き込む本番サービスか？」が分かれ目です。個人開発・プロトタイプ・テストなら SQLite で十分。不特定多数が同時に書き込む本番Webサービスなら PostgreSQL/MySQL が基本です。
4. NoSQL の代表 —— 用途で選ぶ
RDB が「万能で堅実な本棚」なら、NoSQL は「特定の用途に特化した専用道具」です。
ドキュメント型 MongoDB —— 形が変わるデータに
MongoDB は、JSON（→ 第3章）のような形がころころ変わるデータを保存するのに向きます。事前に列（スキーマ）を決めなくてよいので、「今後データの項目が増えそう・形が固まっていない」場面で柔軟です。
キー・バリュー型 Redis —— 超高速な読み書き
Redis は、「鍵に対する値」を超高速で読み書きするのに特化しています。ただし電源を切ると消える可能性がある（インメモリ——データをメモリ上に置く方式が基本のため）ため、消えて困るメインデータではなく、一時的なデータ（キャッシュ・一時セッション等）向けです（→ 第9章 キャッシュ）。
⚠ NoSQL = RDB より優れている、ではない: NoSQL は特定の用途で高速・柔軟ですが、厳密な整合性や**複雑な関連（リレーション）**では RDB に分があります。「新しいから NoSQL」で選ぶのは禁物です。用途に合うかで選ぶのが適材適所です。
5. 🔑 「何で選ぶか」の判断軸
ここが本章の核心の2つ目です。具体的な製品名を覚えるより、「どの軸で選ぶか」の判断フレームを持つ方が応用が効きます。以下の5つの軸で、目的を整理します:
| 判断軸 | 問うべきこと | 選び方の目安 |
|---|---|---|
| 規模 | データは数十万件？ 億件？ | 大規模 → サーバー型 RDB / NoSQL |
| 同時書き込み | 同時に書き込む人は1人？ 何千人？ | 大人数同時 → PostgreSQL/MySQL・Redis |
| データの形 | 形は固定？ ころころ変わる？ | 固定 → RDB／柔軟 → ドキュメント型 |
| 運用コスト | サーバー管理できる？ 手軽さ優先？ | 手軽さ → SQLite／管理可 → サーバー型 |
| 検索の複雑さ | 複雑な関連・集計？ 単純な取得？ | 複雑 → RDB／単純高速 → Redis |
補足: トランザクションと ACID
RDB の強みの1つがトランザクション（transaction／「一連の処理を1つのまとまりにする」仕組み）です。「送金」なら「Aの口座から減らす」＋「Bの口座に増やす」をセットで成功か、両方なかったことかにできます。この整合性の性質を ACID（アシッド）と呼びます:
- 原子性（Atomicity）: 全体で成功か・さもなければ全てなかったことに
- 一貫性（Consistency）: 常にルールを満たす状態を保つ
- 隔離性（Isolation）: 同時実行が互いに干渉しない
- 耐久性（Durability）: 保存したら電源が切れても消えない
💡 「お金など絶対に狂ってはいけないデータ」には、ACID を強く持つ RDB が基本です。「少し狂っても速度優先」なデータ（アクセスカウント等）には、緩い整合性で高速な NoSQL も選択肢に入ります。何を優先するかで選ぶ、という具体例です。
6. なぜ「適材適所」が開発の作法なのか
ここまでを読むと、データベース選びが「名前を知っているか」でなく**「目的に合わせて判断できるか」**の問題だと分かります。
作法として位置づけられる理由
- 過剰選びを避ける —— 小さなツールに大規模向けDBを選ぶと、運用コストだけで疲弊する
- 不足選びを避ける —— 大規模サービスに軽量DBを使うと、成長した時に詰まる
- 両方を組み合わせる —— 現実のサービスは**RDB + キャッシュ層（Redis）**等の組み合わせが普通
面接・実務での意味
「データベース、何を使っていますか？ なぜそれを選んだのですか？」
この質問は、単に「名前を言えるか」でなく**「選んだ理由を説明できるか」を聞いています。「規模が小さいので SQLite で運用コストを抑えた」「同時書き込みが多い本番なので PostgreSQL にした」と理由付きで選べる**人が、現場で信頼されます。
💡 ORM（オーアールエム／Object-Relational Mapping／オブジェクト関係マッピング）: プログラムのコードとデータベースの間を橋渡しし、SQL を直接書かずにデータ操作できる仕組み。RDB の操作を書きやすくする定番の道具です。ただし「ORM を通すと何が起きているか」を理解しておかないと、遅いクエリを生むことがある点に注意。
7. よくある落とし穴と対処
| 落とし穴 | 何が起きるか | 正しい対応 |
|---|---|---|
| 最初から大規模向けを選ぶ | 小規模なのに運用コストで疲弊する | まずはSQLite 等の軽量版で始め、必要になったら移行を検討 |
| SQLite を大規模同時書き込みに使う | ロックが頻発して詰まる | 同時書き込みが多い本番はサーバー型（PostgreSQL 等）へ |
| RDB に無理やり非構造化データを詰める | 表が複雑化し、運用が破綻する | 形が柔軟なデータはドキュメント型も検討 |
| インデックスを貼らない | 検索が遅い（全件走査になる） | よく検索する列にインデックスを設定する |
| インデックスを貼りすぎる | 今度は書き込みが遅くなる | 検索速く＝書き込み遅、のトレードオフを理解して最小限に |
| バックアップを怠る | 障害・誤操作でデータが消えて戻せない | 定期的なバックアップと復元確認を必ず仕組み化 |
💡 インデックス（index／「索引」）: 本の巻末の「索引」と同じ仕組み。特定の列から高速にデータを見つけられるようにする仕組みです。ただし索引を作る・更新するコストもかかるため、「検索が速くなる＝無条件で良い」ではありません。
まとめ
- データベースはデータの保存・検索・整合性を担う仕組み。万能な1つは存在せず、目的で選ぶのが適材適所
- RDB（表で管理・SQL・整合性強）と NoSQL（柔軟・特定用途で高速）の2大分類
- RDB の中でも: SQLite（ファイル1つ・軽量・同時書き込み弱）vs PostgreSQL/MySQL（サーバー型・同時書き込み強・運用コスト）
- NoSQL は用途別: MongoDB（形が変わるデータ）・Redis（超高速な一時データ）
- 判断軸は規模・同時書き込み・データの形・運用コスト・検索の複雑さの5つ
- お金等の絶対に狂ってはいけないデータは ACID の強い RDB が基本
💡 次のステップ: データを「保存する」仕組みが見えました。次は、動いているシステムの状態を観察する作法です。第8章では、ログ・モニタリングにより「いま正常に動いているか・問題が起きているか」を把握する方法を扱います。