web-dev-qa-db-ja.com

ベストプラクティスデータベース設計-ユーザー評価表

協調フィルタリングアルゴリズム用のアイテムのユーザー評価を格納するテーブルを作成したいと思います。これまでのところ、私のテーブルは次のようになります。

IID | UID |格付け.

item ID |user id |rating.

協調アルゴリズムの例から、テーブルは次のようになります。

Item ID | Rating U1 | Rating U2 | ... | Rating Un

つまり、新しいユーザーがサインアップするたびにテーブルを変更（拡張）する必要があります。または、ユーザーごとに新しいテーブルを作成する必要があります。どちらも非常に効率的なソリューションではないようです。誰かが私を正しい方向に向けることができますか？

ありがとう

database-designtabledenormalization
2
cactus_amigo

最初の設計は正規化され、2番目の設計は0NF（非正規化）です。あなたは非正規化する理由を何も述べておらず、正当な理由なしに非正規化すべきではありません。

2番目の設計が非常に悪い理由は次のとおりです。

  • それぞれの場合で、平均評価を計算するためのクエリがどのようになるかを考えてください。

  • ユーザー数が、DBMSのテーブルあたりの列数の制限を超えた場合にどうするかを考えてください。

  • 外部キー値が原因でデータの重複が懸念されるとコメントで述べましたが、データがまばらに表示されているためにどれだけのスペースを無駄にしていますか？ 1,000人のユーザーがいて、平均して各アイテムを評価したユーザーが10人だけの場合、アイテムごとに990ビットのnullフラグを浪費しています。

  • 新しい列が使用可能な空き領域に収まらない場合、データのチャンクを移動する必要があるため、ユーザーが登録するときにテーブルの幅を常に変更すると、パフォーマンスに大きな影響を与える可能性があります。

あなたはベストプラクティスを求めました。 トランザクションデータのベストプラクティスは第3正規形です（該当する場合はそれ以上）。

3
Joel Brown

最初のデザインはより良いデザインです

アイテムID |ユーザーID |評価

Resons：-

  • ユーザーごとに、テーブルのスキーマを変更する必要がないため、インデックスも変更する必要があります。

  • パフォーマンスに関しては、より優れたインデックスオプションを提供します。

  • 管理しやすい列数が少ないテーブル。

  • 簡単なDML操作。

  • 将来の変更/要件に柔軟に対応

ユーザー評価ごとに挿入クエリが必要で、選択も簡単です。

UserIdとItemIdの組み合わせは一意であり、制約/インデックスの作成に使用できます

2
vijayp