この記事の要点

RDBMS: MySQL / PostgreSQL / Oracle / SQL Server / SQLite / MariaDB NoSQL: MongoDB（ドキュメント） / Redis（KVS） / Cassandra / DynamoDB NewSQL: CockroachDB / TiDB（分散だが SQL と ACID を両立） ACID（Atomicity / Consistency / Isolation / Durability）とトランザクション 正規化（第1〜第3 正規形）、インデックス、Foreign Key、ER 図、ORM

データベースの大分類

分類	代表製品	得意	苦手
RDBMS	MySQL / PostgreSQL / Oracle / SQL Server	整合性・複雑クエリ・JOIN	水平スケール
KVS	Redis / Memcached / DynamoDB	高速・キャッシュ	複雑クエリ
ドキュメント	MongoDB / Couchbase	スキーマレス・JSON 自然	JOIN・トランザクション
カラム指向	Cassandra / HBase / ClickHouse	大量書き込み・分析	個別行参照
グラフ	Neo4j / Amazon Neptune	関係探索・推薦	大量バルク処理
時系列	InfluxDB / TimescaleDB	計測データ・IoT	汎用 OLTP
NewSQL	CockroachDB / TiDB / Spanner	水平スケール + ACID	運用ノウハウ未成熟
全文検索	Elasticsearch / OpenSearch / Solr	あいまい検索・スコアリング	更新の即時性

主要 RDBMS の特徴

製品	ライセンス	特徴	主な用途
MySQL	GPL + Oracle 商用	軽量・採用実績豊富	Web アプリ全般
MariaDB	GPL	MySQL フォーク、互換性高	OSS 志向の Web
PostgreSQL	PostgreSQL ライセンス	SQL 標準準拠・拡張機能豊富 (PostGIS, pg_trgm)	分析系・GIS・複雑要件
Oracle Database	商用	最高性能・大規模本番運用	金融・基幹システム
SQL Server	商用	Windows と密接連携 (T-SQL)	Windows 系業務
SQLite	パブリックドメイン	ファイル DB・組み込み	モバイル・テスト・小規模

ACID とトランザクション

ACID は RDBMS が満たす 4 つの性質です:

性質	意味	例
Atomicity（原子性）	全実行か全取消か	振込で片方だけ反映されない
Consistency（整合性）	制約を常に満たす	FK 違反は commit させない
Isolation（隔離性）	同時実行が直列実行と同じ	ダーティリードを防ぐ
Durability（耐久性）	commit 後は失われない	クラッシュ後も復旧可能

-- トランザクションの基本
BEGIN;  -- または START TRANSACTION

UPDATE accounts SET balance = balance - 1000 WHERE id = 1;
UPDATE accounts SET balance = balance + 1000 WHERE id = 2;

-- すべて成功したら確定
COMMIT;

-- 途中でエラーなら取り消し
ROLLBACK;

-- 分離レベル
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;     -- PG/Oracle 既定
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;    -- MySQL InnoDB 既定
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;       -- 最高、ロック競合増

正規化（Normal Form）

正規形	条件	違反例
第 1 正規形 (1NF)	1 セル 1 値（繰り返しグループ無し）	tags = "PHP,Laravel,MySQL"
第 2 正規形 (2NF)	1NF + 部分関数従属を排除	複合キーの一部にだけ依存する列
第 3 正規形 (3NF)	2NF + 推移的関数従属を排除	user_id → dept_id → dept_name の dept_name 持ち込み
BCNF / 4NF / 5NF	より厳格な分解	実務ではあまり意識しない

実務では「3NF を基本としつつ、検索が遅い部分は意図的に非正規化」がセオリーです。

インデックスと外部キー

-- 主キー（自動的にユニークインデックスが作られる）
CREATE TABLE users (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    email VARCHAR(255) NOT NULL UNIQUE,    -- UNIQUE インデックス
    name VARCHAR(100) NOT NULL,
    created_at DATETIME NOT NULL
);

-- 通常インデックス
CREATE INDEX idx_users_created_at ON users (created_at);

-- 複合インデックス（先頭列から左寄せで使われる）
CREATE INDEX idx_orders_user_status ON orders (user_id, status);

-- 部分インデックス（PostgreSQL）
CREATE INDEX idx_orders_active ON orders (created_at) WHERE status = 'active';

-- 外部キー制約
CREATE TABLE orders (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    user_id BIGINT NOT NULL,
    amount INT,
    FOREIGN KEY (user_id) REFERENCES users(id)
        ON DELETE CASCADE
        ON UPDATE CASCADE
);

レプリケーションとシャーディング

手法	目的	仕組み
主従レプリケーション	読み取り負荷分散・冗長化	書きは Primary、読みは Replica
マルチマスター	書き込みも分散	競合解決が必要 (Galera, BDR)
シャーディング	巨大データの水平分割	ユーザー ID 等でハッシュ分散
パーティショニング	巨大テーブル内分割	日付や ID で分割 (RANGE/HASH/LIST)
Read Replica	クラウドの非同期 Replica	RDS / Cloud SQL の機能

NoSQL の概要

// MongoDB（ドキュメント型）
db.users.insertOne({
  name: "taro",
  age: 30,
  tags: ["php", "laravel"],
  address: { city: "Tokyo", zip: "100-0001" }
});
db.users.find({ age: { $gte: 18 }, "address.city": "Tokyo" });

// Redis（KVS）
SET user:1:name "taro"
EXPIRE user:1:name 3600
LPUSH queue:emails "user@example.com"
HSET user:1 name "taro" age 30
ZADD leaderboard 1500 "alice" 1800 "bob"

ORM（Object-Relational Mapping）

言語	代表 ORM
PHP	Eloquent (Laravel) / Doctrine (Symfony)
Java	Hibernate / JPA / MyBatis
Python	SQLAlchemy / Django ORM
Node.js	Prisma / TypeORM / Sequelize
Ruby	ActiveRecord (Rails)
Go	GORM / sqlc / ent
C#	Entity Framework Core

ER 図（Entity Relationship Diagram）

テーブル間の関係を可視化する図。1:1 / 1:N / N:M を矢印で表現します。

• 1:1 — ユーザー ↔ プロフィール
• 1:N — ユーザー → 注文（一人が複数注文）
• N:M — 学生 ↔ 科目（中間テーブルが必要）

用途別 DB 選定の目安

用途	推奨
Web アプリ全般	MySQL / PostgreSQL
キャッシュ・セッション	Redis
大量ログ・イベント	Elasticsearch / ClickHouse
IoT 計測データ	InfluxDB / TimescaleDB
金融基幹	Oracle / SQL Server
サーバーレス・低運用	DynamoDB / Firestore
分析・BI	BigQuery / Snowflake / Redshift

FAQ

Q: MySQL と PostgreSQL、どちらを選べばいい？
A: シンプル & レプリケーション豊富なら MySQL、複雑クエリ & 拡張機能 (PostGIS, JSONB) なら PostgreSQL。新規案件は PostgreSQL の採用が増えています。

Q: NoSQL を採用すべきタイミングは？
A: スキーマが頻繁に変わる、JOIN が不要、水平スケールが必須、のいずれかが当てはまるとき。大抵の Web アプリは RDBMS + Redis で十分です。

Q: ORM と生 SQL、どう使い分ける？
A: 基本は ORM、大量データ集計など性能クリティカルな箇所だけ生 SQL。混在は普通の構成です。