SQL vs NoSQL：アプリにはどちらのデータベースを使うべき？

SQLデータベース（リレーショナルデータベースとも呼ばれます）は、定義された構造、つまり行と列を持つテーブルにデータを保存し、関連するテーブル同士をリンクします。問い合わせにはSQL言語を使います。Postgres、MySQL、SQLiteが例です。NoSQLデータベースは、ドキュメント、キーバリューのペア、ワイドカラム、グラフなど、別の方法でデータを保存し、通常はより柔軟な構造を許容します。MongoDB、Redis、DynamoDB、Firestoreが例です。多くのビジネスアプリでは、SQLデータベースが妥当な初期選択です。NoSQLは特定の用途で力を発揮します。

AIで構築するときにこの選択が重要な理由

データベースは、後から変更するのが最も難しいアプリの部品の一つです。画面は午後一つで作り直せますが、何年分もの顧客データを別の種類のデータベースへ移すのはプロジェクトになります。

AIアプリビルダーがデータ保存を追加するとき、ビルダーはこれらのどれかを選んでいます。違いを知っておくと、次のことに役立ちます。

• データの形を理解する。 後から聞きたい質問（「製品ごとの月別売上」など）にデータが答えられるかを判断できます。
• プラットフォームの選択を判断する。 ドキュメントデータベースを土台にしたプラットフォームもあれば、リレーショナルデータベースを土台にしたプラットフォームもあります。それぞれの代表例として、SupabaseとFirebaseの比較 をご覧ください。
• ベンダーロックインを避ける。 SQLは共通の標準なので、リレーショナルデータは通常、プロバイダー間で移行しやすいです。

身近なたとえ

SQLデータベースは、列が厳密に決められた、丁寧に設計されたスプレッドシートの集まりのようなものです。顧客用のシートがあり、注文用のシートがあり、各注文の行はIDで顧客の行を指しています。シート内のすべての行は同じ列を持ちます。事前の計画は必要ですが、シートをまたいだ質問は簡単で、データは整然と保たれます。

NoSQLドキュメントデータベースは、フォルダーが詰まったファイルキャビネットのようなものです。顧客ごとのフォルダーには、その人の詳細と注文がまとめて入っており、あるフォルダーだけに余分な書類が入っていることもあります。1人の顧客の情報をまるごと取り出すのは素早くできます。一方で「先月、全員が何を注文したか」を知るには、多くのフォルダーを開く必要があります。

実際の違い

「NoSQL」は一つのものではありません。主な種類は次のとおりです。

具体例：同じショップのデータを2通りで保存

1人の顧客と、その注文を持つ小さなオンラインショップを考えます。

SQL（リレーショナル）： データはテーブルに分けられ、IDでリンクされます。

-- customers: id=1, name='Lena Ortiz'
-- orders:    id=101, customer_id=1, total=42.00
--            id=103, customer_id=1, total=25.00

SELECT c.name, SUM(o.total)
FROM customers c JOIN orders o ON o.customer_id = c.id
GROUP BY c.name;

Lenaがメールアドレスを変更しても、変更は1か所で済みます。「今月の顧客ごとの売上合計」も1回の問い合わせで取得できます。

NoSQL（ドキュメント）： 彼女の注文は、彼女のドキュメントの中に入れられます。

{
  "_id": "cust_1",
  "name": "Lena Ortiz",
  "email": "lena@example.com",
  "orders": [
    { "id": 101, "total": 42.00, "items": ["Green tea"] },
    { "id": 103, "total": 25.00, "items": ["Teapot"] }
  ]
}

注文をすべて含めて彼女のプロフィールページを表示するのは、1回の読み取りで済みます。しかし、全顧客にまたがる質問（今月最も売れた製品など）は手間がかかります。同じ製品の詳細が多くの注文にコピーされている場合は、それらを同期させることがアプリ側の仕事になります。

どちらが間違いというわけではありません。問題は、アプリがどのパターンを最も多く使うかです。

選び方

次のような場合は、リレーショナルSQLデータベースが通常の初期選択として適切です。

• ユーザー、チーム、予約、請求書、製品など、関連するデータが多い。
• レコードをまたいだレポート、絞り込み、合計が必要になる。
• 金銭、在庫数、権限など、正確さが重要である。

次のような場合は、NoSQLデータベースの検討に値します。

• 高速なキャッシュやセッションストアが必要。この用途では Redis がよく使われ、多くは SQL データベースと 併用 されます。
• イベントログやセンサーの値のように、件数が非常に多く、シンプルで独立したレコードを扱う。
• Firebaseの Firestore のように、NoSQLを中心に設計されたプラットフォーム上で、そのリアルタイム機能が主な魅力になっている。

SQLを信頼できる情報源（マスター）として使い、キャッシュや特定の機能のためにNoSQLストアを加えるなど、両方を併用しているアプリも多くあります。

主要な用語

よくある誤解

• 「NoSQLにはスキーマがない」。 データには必ず形があります。NoSQLではデータベースがその形を強制しないことがあるため、代わりにコードがそれを守る必要があります。
• 「SQLはスケールしない」。 リレーショナルデータベースは非常に大規模なサービスを動かしています。ほとんどのアプリは、その限界に近づくことすらありません。
• 「NoSQLは常に速い」。 得意とするパターンでだけ速いのです。横断的なレポートは遅くなることがあります。
• 「一度選んだら変えられない」。 多くのアプリは両方を組み合わせています。また、PostgresのようなSQLデータベースもJSONを保存できるため、少数の柔軟なフィールドのためにNoSQLが必要になるわけではありません。
• 「NoSQLはSQLを使えないという意味」。 名前は通常「SQLだけではない」と読まれ、一部のNoSQL製品はSQLに似た問い合わせ言語を提供しています。

AIビルダーに聞くこと

• 「このアプリはどの種類のデータベースを使っていて、なぜ私のデータに合うのですか？」
• 「テーブルやコレクションと、それらの関係を図に描いてください。」
• 「6か月後に必要になりそうなレポートは何ですか？このデータベースで簡単に答えられますか？」
• 「本当に柔軟にすべきフィールドが少数であれば、2つ目のデータベースを追加する代わりに、Postgresの中にJSONとして保存してください。」
• 「速度の問題が実際に計測されたときにだけ、キャッシュを追加してください。」

Mythexのデータベース

Mythexは、データベースが必要なプロジェクトに専用のPostgresデータベース（リレーショナルSQLデータベース）を用意します。アプリが必要とした時点で、チャットで依頼するか、/database コマンドを使えば追加されます（Database）。これは、ユーザー、予約、注文、レポートといった、多くのビジネスアプリに適しています。ホスト型のドキュメントデータベースなど、特定の外部サービスが必要な場合は、エージェントがプロジェクトのシークレットとして保存したキーを使って接続するコードを書けます。SQLという言語自体について詳しく知りたい場合は、SQLとは何か をお読みください。

よくある質問