SQLとNoSQLの違いを図にした。形を先に決めるかどうか

• 違いは形を先に決めるか、入れるときに決まるか
• 表は全行で列が共通。ドキュメントは1件ごとに項目が違ってよい
• 優劣ではなく、扱うデータの形が定まるかで選ぶ

比較記事は多いが、だいたい「柔軟」「スケールする」といった言葉で終わる。何がどう違うのかを図にした。

持ち方が違う

表の形

先に列を決め、すべての行をその形に当てはめる。持っていない項目は空として扱われる。

列を増やすには表の定義そのものを変える必要がある。行が多いと、この変更に時間がかかる。

強み

形が決まっているので、つじつまを保ちやすい。トランザクションと組み合わせると、複数の表にまたがる更新でも中途半端な状態を残さない。

もうひとつ、同じ情報を1か所にだけ持てる。住所を別の表に分けておけば、変更するのは1行で済む。各所に書き写してあると、直し漏れがそのまま食い違いになる。

ドキュメントの形

MongoDBの公式文書では、ドキュメントがデータの基本単位とされ、データはBSONという形式で保存される。BSONはJSONの二値表現で、JSONより多くの型を持つと説明されている。

構造についての記述はこうだ。

フィールドの値には、他のドキュメント、配列、ドキュメントの配列を含む、あらゆるBSONの型を使える。

つまり入れ子をそのまま入れられる。表の形なら別の表に分けて結合することになる構造を、1件の中に収められる。

何が楽になるのか

公式はこう述べている。

オブジェクト指向のデータモデルにより、コード内のオブジェクトの構造をそのまま反映した形でデータを持てる。これにより、リレーショナルデータベースで必要だった対応付けの作業が不要になる。

プログラム側の構造と保存の形が一致するので、変換の層が要らなくなるという話だ。

制限もある

1つのドキュメントの大きさには上限があり、16メビバイトと公表されている。何でも際限なく入れ子にできるわけではない。

どちらを選ぶか

判断は形が定まるかどうかに尽きる。

• 形が定まる（会計、在庫、予約、会員）→ 表の形。つじつまを保つ仕組みが揃っている
• 形が定まらない（取り込んだ外部データ、設定、ログ、記事ごとに項目が違うもの）→ ドキュメントの形

注意点として、形が自由だということは、形を自分で管理するということでもある。入れるときに弾いてくれないので、後から「ある項目が無い件」「型が違う件」が混ざる。

WordPressはどちらか

表の形で動いている。ただし、記事ごとに自由な項目を持たせる仕組みが用意されていて、これは「キーと値の組を別の表に積む」形で実現されている。

形を固定したまま自由さを足す作りなので、項目が増えるほど、1件を組み立てるのに読む行が増える。表示が遅い原因がここにあることもある。調べる順番は表示が遅い原因を、順番に調べた作業に書いた。

結合という考え方

表の形では、関連する情報を別の表に分けて、必要なときに結合して取り出す。注文の表と会員の表を分けておき、会員IDでつなぐ、という作り方だ。

利点は、会員情報を直すのが1か所で済むこと。代償は、取り出すたびにつなぐ処理が走ること。つなぐ回数が多い画面は、そのぶん重くなる。

ドキュメントの形では、注文の中に会員情報を埋め込むこともできる。取り出しは速いが、会員情報を直すときに、埋め込んだ全部を直すことになる。

どちらも「読むのを速くするか、直すのを楽にするか」の取り引きになっている。

まとめ

• 違いは形を先に決めるか。優劣ではない
• 表は全行で列が共通。列の追加は定義の変更になる
• ドキュメントは1件ごとに項目が違ってよく、入れ子をそのまま持てる
• ドキュメントはコード側の構造と一致させやすい
• 1ドキュメントの上限は16メビバイト
• 形が自由＝形を自分で管理するということ

出典

• MongoDB Manual「Documents」（BSON、入れ子と配列、オブジェクトモデルとの対応、サイズ上限）
• MySQL 8.4 Reference Manual「Glossary: ACID」（表の形における保証）

図は本記事のために作成したもの。本記事は2026年10月13日時点の内容に基づく。