「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を選べるようになりたい。。