SQL

概要

（Structured Query Language・構造化問い合わせ言語）は、PostgreSQL、MySQL、SQLite、SQL Server といったリレーショナルデータベースを照会・操作するための標準言語です。レストランで料理を注文する場面を思い浮かべてください。皿に何を載せてほしいかを伝えるだけで、どう調理するかは伝えません。SQL も同じように動きます。どんな結果が欲しいかを記述すると、データベースエンジンがそれを効率的に取得する方法を考えてくれます。これを宣言的と呼びます。

強み

宣言的: 行をどうループするかではなく、何が欲しいかを述べる。
数十年にわたって実証され、成熟したエンジンと強い一貫性保証を備える。
集合ベースの操作（join、集約、ウィンドウ関数）が簡潔かつ高速。
移植性がある — 中核的な SQL はほとんどのリレーショナルデータベースで動く。

トレードオフ

方言が異なる（Postgres と MySQL と SQLite）ため、移植性は完全ではない。
遅いクエリを書きやすく、性能はインデックスとクエリプランに依存する。
汎用言語ではなく、制御フローやロジックは扱いにくい。
スキーマ変更（マイグレーション）は本番環境では慎重さが必要。

使いどころ

データがリレーショナルで構造によって照会される場合はいつでも SQL を選びましょう。レポーティング、分析、アプリケーションのバックエンド、データの整合性と join が重要なあらゆるシステムに向いています。構造化データに対する集約やアドホックな問いには最適なツールであり、ほぼすべてのバックエンド言語と組み合わせられます。

バイブコーディングとの相性

AI アシスタントは SQL が得意で、平易な英語の質問を驚くほどうまくクエリに翻訳できますが、スキーマを推測してしまうことがあります。実際のテーブル定義（CREATE TABLE 文）を貼り付け、使用する具体的なデータベース（Postgres、SQLite など）を伝えて、正しい方言と関数を使うよう AI を誘導しましょう。クエリの説明を求め、遅いクエリにはインデックスを提案させましょう。値をクエリ文へ直接つなぐのではなく、ユーザー入力は常にパラメータ化させましょう。入力欄に名前ではなく命令を打ち込む人を想像してください。その文字をそのままクエリに貼り付けると、データベースがその命令を実行してしまうことがあります。ユーザー入力を切り離しておけばこれを防げます。この攻撃を SQL インジェクションと呼びます。生成されたクエリは、本番環境に対して実行する前に小さなサンプルで検証してください。

SELECT u.name, COUNT(o.id) AS order_count
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
WHERE u.active = true
GROUP BY u.name
HAVING COUNT(o.id) > 5
ORDER BY order_count DESC;