リレーショナルDBは、表と関係でデータをきっちり整理するDB。
NoSQLは、文書やキー・値など、決まった表以外の形でもデータを扱いやすいDBの総称です。
比べる軸
リレーショナルDBとNoSQLは、「どちらが上か」ではなく、データの置き方と使い方が違います。Webアプリでよく出てくる会員、注文、商品、投稿などをどう整理するかで選び方が変わります。
最初は、リレーショナルDBは表計算ソフトのように行と列でそろえるDB、NoSQLは用途に合わせて文書やキー・値などの形を選べるDB、と考えるとつかみやすいです。
表でそろえるか、文書やキー・値などで持つか。
関係をたどる検索か、特定用途で速く読む処理か。
構造を先に決めるか、あとから形を変えやすくするか。
リレーショナルDB
リレーショナルDBは、データを表に分けて保存し、IDで表同士をつなげます。たとえばユーザー表、注文表、商品表を分けておき、注文の中に「どのユーザーか」「どの商品か」を示すIDを持たせます。
この形にすると、データの重複を減らしやすく、注文金額の集計やユーザー別の履歴表示などを安定して扱えます。PostgreSQLやMySQLは、このタイプの代表例です。
会員、注文、請求、在庫など、整合性が大事なデータ。
複数の表をつないだ検索、集計、条件での絞り込み。
表の設計を大きく変えるときは、移行作業が必要になりやすい。
NoSQL
NoSQLは、リレーショナルDB以外のDBをまとめて指す言葉です。文書形式で保存するもの、キーと値で高速に読むもの、データ同士のつながりを扱うものなど、いくつかの種類があります。
代表例として、文書型のMongoDB、キー・値型やキャッシュ用途で使われるRedisなどがあります。表にそろえにくいデータや、特定の読み取りを速くしたい場面で選ばれます。
投稿、プロフィール、設定など、項目が変わりやすいデータを扱いやすい。
セッション、キャッシュ、ランキングなどを速く読む用途で使いやすい。
ユーザー同士の関係やタグのつながりなどをたどりやすい。
選び方の目安
個人開発や一般的なWebアプリでは、まずPostgreSQLやMySQLのようなリレーショナルDBを選ぶと扱いやすいことが多いです。会員、注文、投稿、権限のように関係がはっきりしたデータを、安全に扱いやすいからです。
NoSQLは、データの形が頻繁に変わる、キャッシュを速く読みたい、大量のログを用途別にためたい、といった理由が見えてから選ぶと判断しやすくなります。
PostgreSQLやMySQLなどのリレーショナルDBから考える。
文書型などのNoSQLが合うか確認する。
RedisのようなDBを補助的に使う選択肢もある。
ここまでのまとめ
リレーショナルDBは、表で整理し、表同士の関係をIDでつなぐDBです。NoSQLは、文書、キー・値、つながりなど、用途に合わせた形でデータを扱うDBの総称です。
多くのWebアプリはリレーショナルDBから始めると考えやすく、NoSQLはデータの形や読み方に明確な理由があるときに選ぶと整理しやすいです。