2012-10-29 113 views
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

我試圖決定是它是否是一個不好的事情也存儲在第二個表中的數據。我應該將user_notifications表視爲交互表,而不是實際可靠存儲用戶數據的地方嗎?

+0

沒有人可以在不知道使用量的情況下回答這個問題。經驗法則,你的系統使用的越少,它越接近理論(規範化等),你的體積越大,你會發現自己需要打破理論 –

回答

2

我要處理這個任務的方式是將您正在記錄的數據分解爲可管理和邏輯塊(儘管這受到使用量和您想要提取的實際信息的影響)。

舉例來說,如果情況是,你正在錄製以下類型的數據:

  • 用戶信息(電子郵件,ID,姓名等)
  • 視頻(ID,標題,文件名等)
  • 視頻觀看(VIDEO_ID,USER_ID,time_watched_for)

然後,它可能是有意義的存儲在單獨的表中的數據,使得該信息被以有意義的方式分離。

所以在這個意義上它也將是有意義的有你的通知初始表(雖然這看起來更像是一個通知日誌表):

  • 通知表(ID,receiver_id,SENDER_ID,動作,ACTION_TYPE , ENTITY_ID,時間戳)

本質上,在一個單獨的表中存儲的數據不是一個好主意,只要有一個有意義的或邏輯的理由它有存儲諸如邏輯數據分離。

0

一般情況下,這是一個壞主意,在你的數據庫(非標準化),因爲冗餘數據:

  • 它佔用了更多的空間。
  • 維護起來更麻煩,需要花費更長的時間(您正在將相同的數據寫入多個位置)。
  • 你可能會得到一個不一致的數據庫(比如,如果你搞砸了上面的一點,並不寫入所有你需要的地方)。

我能想到的冗餘數據的唯一原因是因爲您絕對需要性能提升來進行某種形式的連接,您將一直在進行連接閱讀。如果您有冗餘數據,則可以消除加入/查找並從單個表中直接讀取。