DB設計について、「いつ、何に、誰が」を持つテーブルよりも、「誰が、その他の情報」という方がいいのではないか？

Question

よくある「いいね機能」などのDB設計で質問があります。

「いつ、何に、誰が」を持つテーブルよりも、「誰が、その他の情報」という方がいいのではないか？という考えなのですが、

なぜ前者が用いられるのでしょうか？

###「いつ、何に、誰が」を持つテーブル
こちらでは、「user_idが2さんがいいねしている記事」を取得するとき、「user_idが2の行」を複数探し、そこから「updated_at」や「article_id」など複数の列を取得してこなければなりません。

+----+---------------------+------------+---------+
| id | updated_at          | article_id | user_id |
+----+---------------------+------------+---------+
|  1 | 2020-01-25 12:35:43 |          1 |       1 |
|  2 | 2020-01-25 12:35:44 |          1 |       2 |
|  3 | 2020-01-25 12:35:44 |          1 |       3 |
|  5 | 2020-01-25 12:36:16 |          2 |       2 |
+----+---------------------+------------+---------+

###「誰が、その他の情報」を持つテーブル
こちらならば、「user_idが2さんがいいねしている記事」を取得する速度が速いですよね。

「user_idが2の行」は１つしかなく（下記は見やすく2行にはしていますけど）、その１つのdataを取得すれば済むからです。

同様に削除も更新も何もかもこちらの方が早いような気がするのですが、どうなのでしょうか。なぜこちらより上の設計が用いられるのか妥当な理由を知りたいです。

+----+-------------------------------------------------------+---------+
| id | data                                                  | user_id |
+----+-------------------------------------------------------+---------+
|  1 | [{"updated_at":"2020-01-25 12:35:43","article_id":1}] |       1 |
|  2 | [{"updated_at":"2020-01-25 12:35:44","article_id":1}, |       2 |
|    |  {"updated_at":"2020-01-25 12:36:16","article_id":2}] |         |
|  3 | [{"updated_at":"2020-01-25 12:35:44","article_id":1}] |       3 |
+----+-------------------------------------------------------+---------+

Answer 1

同様に削除も更新も何もかもこちらの方が早いような気がするのですが

たしかに、ただ単に入れるだけであれば、この方法でも構いません。個人設定など、「他の項目と全く絡まない」「中身で検索することもありえない」項目については、こういう入れ方で済ませてしまうことも考えられます。

ただし、このようにデータを突っ込んでしまうと、検索・並べ替えなどにまとめて突っ込んだデータを使うのが難しい、あるいは不可能となります。

あと、外部キーもかけられないので、article_idに存在しないIDが来ても、データベースレベルではそれを通してしまいます。

というように、このようなデータのもたせ方をすることは、RDBMS（リレーショナルデータベース）を、単なるデータ置き場としてしか使わない、ことにほかなりません。

Comments

[maisumakun]

なお、「NoSQL」といって、リレーショナル性にこだわらないデータストアの仕組みもあります。データの内容と使い方によっては、NoSQLのほうが便利ということも考えられます。

[theearth]

ご回答の確認が遅くなり申し訳ございません。
ご慧眼、感服いたしました。

考え直したところ次の質問がございます。（長文すみません。）

まず「いいね機能」は当人しか見ず、「他の項目と全く絡まない」情報です。
ただし「中身で検索することもありえない」ではなく、検索・並べ替え・削除（以下「抽出」）も必要です。ここで質問ですが、

抽出は次の流れになりまして、

➀dataからjsonすべて取得
➁そこから抽出するIDを持つ配列を取得

この➀➁の流れは、「いつ、何に、誰が」を持つテーブルからの取得よりも早くないでしょうか？

ユーザーが１０万人いたとしたら、「いつ、何に、誰が」を持つテーブルにその１０万人のアクションが数百万行入ることになります。すると「Aさんのいいね一覧」を抽出する際、わざわざ数百万行から探し出すことになります。

他方で「誰が、その他の情報」を持つテーブルならば、「Aさんのいいね一覧」は１０万行からAさんのdataを探し、先の➀➁を処理するだけになります。

このように比べると、「他の項目と全く絡まない」情報ならば、例え抽出が必要であっても、「誰が、その他の情報」を持つテーブルの方が早いということになりませんでしょうか？

[maisumakun]

> ユーザーが１０万人いたとしたら、「いつ、何に、誰が」を持つテーブルにその１０万人のアクションが数百万行入ることになります。

インデックスを張れば、「特定のuser_idを持つもの」のような条件による検索は一瞬で行なえます。

（逆に、JSONを使ったデータ構造だと、「ある案件についたいいね数」を集計する場合に全JSONを展開する必要が出てきますが、正規化して列に分けて入れていた場合には同様にすぐ集計可能です）

[theearth]

なるほどインデックスというものを知りませんでした。早速試してみたいと思います。ご返信誠にありがとうございます。
すでにベストアンサーは選んでしまっておりますが、また別のところで機会がございましたらどうぞ宜しくお願い致します。

Answer 2

理由は正規化です。
要件次第で、正規化を崩すこともありますが、一般論として正規化されたデータのほうが扱いやすいです。

Comments

[theearth]

正規化、知りませんでした。ありがとうございます。