第9章: SQL方言と競合技術 — PostgreSQL/MySQL/NoSQL/分散SQL/OLAP

「SQL」はひとつではない — 方言の現実

「SQL標準」を謳いつつも、実際のRDBMSが100%標準準拠の例はありません。 PostgreSQLが最も標準準拠度が高いとされ、MySQLが最もゆるく、Oracleは独自拡張が多いのが伝統的な傾向です。 実務での移植性は「方言差を知っているかどうか」で決まります。

SQL vs NoSQL — 2010年代の闘いとその後

2009年頃、「NoSQL」（Not Only SQL）ムーブメントがWebスケール需要と共に急成長。 MongoDB、Cassandra、DynamoDB、Redisなどが登場し、「SQLは古い」と言われた時代がありました。 しかし2020年代にはSQLが再び主戦場に戻ってきています。

NewSQL / 分散SQL — SQLが勝ち戻った

2012年以降、「ACIDと水平スケールの両立」を目指すNewSQLが本格化しました。 火付け役はGoogle Spanner(2012年論文、原子時計とTrueTime APIで分散一貫性を実現)。 その後、オープンソース系が続きます。

OLAP / カラムナ / Lakehouse — 分析系SQLの独立世界

ここまでの文脈は主にOLTP（Online Transaction Processing、オンライントランザクション処理）の世界でした。 一方、分析系のOLAP（Online Analytical Processing）は別のアーキテクチャで進化してきました。 大量の行を集計して少数の数値を出す用途では、列指向(カラムナ)ストレージが圧倒的に有利だからです。

flowchart LR
    subgraph ROW[行指向ストレージ - OLTP]
      R1["Row1: id=1, name=Alice, age=30, dept=Eng"]
      R2["Row2: id=2, name=Bob, age=25, dept=Sales"]
      R3["Row3: id=3, name=Carol, age=35, dept=Eng"]
    end
    subgraph COL[列指向ストレージ - OLAP]
      C1["id列: [1, 2, 3]"]
      C2["name列: [Alice, Bob, Carol]"]
      C3["age列: [30, 25, 35]"]
      C4["dept列: [Eng, Sales, Eng]"]
    end
    style R1 fill:#3b82f6,color:#fff
    style C3 fill:#10b981,color:#fff

ORM論争 — 生SQL派 vs ORM派

アプリ開発におけるSQL利用方法は大きく生SQL派とORM派に分かれ、 しばしば激しい議論の対象になります。

第9章のまとめ

• SQL方言は実務で避けられない。文字列連結、LIMIT vs TOP、UPSERT、自動採番、Boolean型、NULLソートなどDBごとに異なる
• 2010年代のNoSQLブームは落ち着き、2020年代はNewSQL / 分散SQL（Spanner, CockroachDB, TiDB, YugabyteDB, Aurora DSQL）でACIDと水平スケールが両立する時代
• OLTPとOLAPは別物。OLAPは列指向ストレージで集計を高速化。DuckDB, ClickHouse, Snowflake, BigQueryが代表
• DuckDBは「OLAPに対するSQLite」として急成長中。組み込み・依存なしでCSVに直接SQL
• ORM論争は決着がつかないが、型安全SQLビルダー（jOOQ/sqlc/Drizzle/Kysely）が中道路線として台頭

次章はシリーズ最終章。AI時代を迎えたSQLの現在地と未来、Vector型の標準搭載、Text-to-SQL、初級→中級→上級の学習ロードマップを提示します。