- 「SQL vs NoSQL 入門 — 名前とメールアドレスを保存するならどっち？」
はじめに
アドベントカレンダー 12/25 = 25記事目
Web アプリやサービスで「ユーザーの名前とメールアドレス」を保存する場合、どんなデータベースを使えばいいのか？
最近は「RDB（リレーショナルデータベース）」だけでなく、「NoSQL（ドキュメント型データベースなど）」という選択肢もあって、「どれを使えばいいか」が少し迷いやすいです。
この記事では、代表的な RDB の PostgreSQL と、NoSQL の MongoDB を、「名前＋メールアドレスを保存 → 取得する」という例で比べながら、両者の特徴や「どんなときに向いているか」を解説したいと思います。
1. PostgreSQL（リレーショナル DB）の場合
✅ テーブル定義（スキーマを決める）
CREATE TABLE users (
id SERIAL PRIMARY KEY,
name TEXT,
email TEXT
);
- このように「どの項目を持つか」「型は何か」をあらかじめ定義します。
- たとえば name（文字列）、email（文字列）のように。
✅ データの追加
INSERT INTO users (name, email) VALUES ('Taro', 'taro@example.com');
✅ データの確認
SELECT * FROM users;
✅ 表示イメージ（例）
id | name | email
----+--------+-----------------------
1 | Taro | taro@example.com
✅ PostgreSQL の特徴
- データ構造をあらかじめ決める → “型” や “項目” に揺らぎがない。安定。
- 複数のテーブルを関連づけて扱うのに強い。たとえばユーザーと注文、商品のような関係があるときに便利。
- データの整合性（正しさ）や信頼性が比較的高い。複雑なクエリや検索にも対応しやすい。 (geeksforgeeks.org)
✅ 向いているケース（こんなとき使うといい）
- ユーザー情報、商品マスタ、注文履歴など「項目が固定されるデータ」
- いくつものテーブルを関連させて扱う必要があるとき
- データの整合性・信頼性が重要なシステム
2. MongoDB（ドキュメント型 NoSQL）の場合
✅ データ追加（document = JSON のようなデータ形式）
db.users.insertOne({
name: "Taro",
email: "taro@example.com"
});
✅ データ取得／確認
db.users.find().pretty();
✅ 表示イメージ（例）
{
"_id": ObjectId("..."),
"name": "Taro",
"email": "taro@example.com"
}
✅ MongoDB の特徴
- スキーマ（構造）をあらかじめ決めなくても良い — 保存する内容を柔軟に変更できる。 (mongodb.com)
- 異なる構造のデータを同じコレクションに混ぜてもよいので、柔軟性が高い。
- 初期段階でデータ構造が定まっていない、または頻繁に変わる可能性があるアプリに向く。 (GlobalCloudTeam)
✅ 向いているケース（こんなとき使うといい）
- ログデータ、設定データ、ユーザーのプロフィールのように、項目が柔軟・可変なデータ
- 開発途中で仕様変更が多く、データ構造がころころ変わる可能性があるとき
- 最初は簡単に、小規模で始めて、あとからデータ構造を調整したいとき
3. PostgreSQL と MongoDB の違いをざっくり比較
| 項目 | PostgreSQL（RDB） | MongoDB（NoSQL） |
|---|---|---|
| データ形式 | 表（テーブル） | ドキュメント（JSONライク） |
| 構造（スキーマ） | 固定 | 柔軟（スキーマレス） |
| ID の扱い | 数値など（自動採番） | ObjectId（自動採番） |
| 柔軟性 | △（構造を変えると手間がかかる） | ◎（自由にデータの形を変えられる） |
| 向いている用途 | 安定した構造のデータ、複数表の関係があるとき | 変動のあるデータ、開発の初期段階など |
| 長所 | 整合性・信頼性が高く、複雑なクエリに強い | 柔軟性が高く、素早い開発に向いている |
| 短所 | スキーマ変更が手間、構造が固い | 複雑な関係や参照の扱いが苦手なこともある |
4. どちらを選ぶべき？ — 実践的な考えかた
- ユーザー情報、注文履歴、商品データなど「構造が安定／変わらない」 → PostgreSQL
- ログ、ユーザー設定、将来的に項目が増減するかもしれないデータ → MongoDB
- 開発の初期段階でとりあえずデータを保存・確認したい → MongoDB（手軽） → 後で構造が固まったら PostgreSQL に移行、もあり
ただし、最近では PostgreSQL でも JSON 型（ドキュメント型に近い保存形式）を使うことで、柔軟性と整合性の両立ができるようになってきています。つまり「RDB か NoSQL か」は“ゼロかイチか”ではなく、“要件に応じて柔軟に選ぶ”ものです。 (Logto blog)
さいごに
データベースには「リレーショナル型（RDB）」と「ドキュメント型／NoSQL型」のように、性格の違うものがあります。
どちらにもメリット・デメリットがあるので、「このデータをどう使いたいか」「どれくらいの柔軟性が必要か」「将来的な構造変更の可能性はあるか」を考えて選ぶのが大事になることが少し理解できました
あとからDBを変えるのは手間がかかるので、最初の設計段階で最適なDBを選べるようになりたい。。