0

だから私はユーザー通知システムを作成しました、そして私は次のように構造化されたuser_notificationsテーブルを持っています：

id
receiver_id
sender_id
action
action_type
entity_id
timestamp

現在、「entity_id」列を介して通知に接続されている他のテーブルに値があります。それで、 videos_watchedというこのテーブルもあるとしましょう：

video_id
user_id
time_watched_for

それらはuser_notifications.entity_idからvideos_watched.video_idに接続されています

私が判断しようとしているのは、2番目のテーブルにもデータを格納するのが悪いことかどうかです。user_notificationsテーブルを、ユーザーデータを実際に確実に保存する場所ではなく、インタラクションテーブルとして扱う必要がありますか？

4

2 に答える 2

2

このタスクにアプローチする方法は、記録しているデータを管理しやすく論理的なチャンクに分割することです (ただし、これは、使用量と引き出したい実際の情報に影響されます)。

たとえば、次のタイプのデータを記録している場合:

  • ユーザー情報（メール、ID、名前など）
  • ビデオ (ID、タイトル、ファイル名など)
  • 視聴した動画 (video_id、user_id、time_watched_for)

次に、情報が意味のある方法で分離されるように、データを別々のテーブルに格納することが理にかなっている場合があります。

その意味では、通知用の初期テーブルを用意することも理にかなっています (ただし、これは通知ログ テーブルのように見えます)。

  • 通知テーブル (id、receiver_id、sender_id、action、action_type、entity_id、timestamp)

基本的に、データを別のテーブルに格納することは、論理的なデータの分離など、そこに格納する意味のある、または論理的な理由がある限り、悪い考えではありません。

于 2012-10-30T00:06:57.653 に答える
0

一般に、データベースに冗長データ (正規化されていない) を含めることはお勧めできません。理由は次のとおりです。

  • それはより多くのスペースを取ります。
  • 維持するのが面倒で、書き込みに時間がかかります (同じデータを複数の場所に書き込んでいます)。
  • 一貫性のないデータベースを取得できます (上記の点を台無しにして、必要なすべての場所に書き込んでいない場合など)。

私が考えることができる冗長なデータを持つ唯一の理由は、あなたが常に行ったり読んだりする何らかの結合のために絶対にパフォーマンスを向上させる必要があるからです. 冗長なデータがある場合は、結合/検索を省略して、1 つのテーブルから直接読み取ることができます。

于 2012-10-30T00:08:25.207 に答える