タイトル: データベース関連
SEOタイトル: データベース関連用語・基礎概念完全ガイド (RDBMS/NoSQL/ACID)
| この記事の要点 |
- 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。混在は普通の構成です。
