2013-06-03 92 views
1

我正在嘗試構建存儲多個用戶消息的數據庫。每個用戶將能夠發送/接收5種不同的消息「類型」(嚴格來說,標籤,實際數據類型將是相同的)。我最初的想法是爲每個用戶創建多個表,代表5種不同的消息類型。我很快就知道這不是一個好主意。我的下一個想法是爲每個消息類型創建一個包含用戶列的表,但我不確定這是從性能角度來看最好的方法。如果用戶1發送100個消息類型1,而用戶3只發送10,會發生什麼?其餘的字段將是空值,我真的不確定這是否有所作爲。思考?建議和/或建議閱讀?先謝謝你!數據庫設計:每個用戶多個表

+0

http://pragprog.com/book/bksqla/sql-antipatterns – dm03514

回答

1

不,(在這個問題上的主題給出的主意)將極大地低效。每次創建新用戶時都需要引入一個新表,並且一次查詢所有這些表將成爲一場噩夢。

單個表來存儲關於消息的信息要容易得多。該表中的每一行都將對應於一個且僅有的消息。

此外,此表應該可能有三個'引用'列:兩個用於將特定消息鏈接到其發送者和接收者,另一個用於存儲其類型,只能分配有限的一組值。

例如:

MSG_ID | SENDER_ID | RECEIVER_ID | MSG_TYPE | MSG_TEXT 
------------------------------------------------------ 
    1 |  1  |  2  | 1  | ....... 
    2 |  2  |  1  | 1  | ####### 
    3 |  1  |  3  | 2  | $$$$$$$ 
    4 |  3  |  1  | 2  | %%%%%%% 

... 

這將是很容易得到雙方的所有消息由有人送(與WHERE sender_id = %someone_id%條款),發送到有人WHERE receiver_id = %someone_id%),某些特定類型的(WHERE msg_type = %some_type%)。但最好的是,可以輕鬆地將這些子句組合起來,以設置更復雜的過濾器。


您最初以爲,似乎什麼,看起來是這樣的:

IS_MSG_TYPE1 | IS_MSG_TYPE2 | IS_MSG_TYPE3 | IS_MSG_TYPE4 
--------------------------------------------------------- 
    1  |  0  |  0  |  0 
    0  |  1  |  0  |  0 
    0  |  0  |  1  |  0 

它可以是NULL!而非0,其核心仍然是相同的。它壞了。是的,您仍然可以通過WHERE is_msg_type_1 = 1條款獲得單一類型的所有消息。但即使是獲得某種特定信息這樣簡單的任務也變得不那麼容易:您必須檢查這5個列中的每個,直到找到具有truthy值的那個爲止。

類似的困難,指望誰試圖計算每個類型的消息的數量的一個(這幾乎是瑣碎的結構上面給出:。COUNT(msg_id)... GROUP BY msg_type

所以,請不要這樣做),除非你有一個非常有力的理由,不要試圖構建你的桌子,以便隨着時間的推移,他們的身高會增加 - 而不是寬度。

+1

完美。我現在不僅瞭解了什麼,而且還了解了爲什麼。謝謝! – user2442072

0

其餘字段將是空值

,除非你是垂直設計數據庫,將不會有剩餘的字段。

user int 
msgid int 
msg text 
0
create table `tv_ge_main`.`Users`( 
    `USER_ID` bigint NOT NULL AUTO_INCREMENT , 
    `USER_NAME` varchar(128), 
    PRIMARY KEY (`ID`) 
) 

create table `tv_ge_main`.`Message_Types`( 
    `MESSAGE_TYPE_ID` bigint NOT NULL AUTO_INCREMENT , 
    `MESSAGE_TYPE` varchar(128), 
    PRIMARY KEY (`ID`) 
) 

create table `tv_ge_main`.`Messages`( 
    `MESSAGE_ID` bigint NOT NULL AUTO_INCREMENT , 
    `USER_ID` bigint , 
    `MESSAGE_TYPE_ID` bigint , 
    `MESSAGE_TEXT` varchar(255) , 
    PRIMARY KEY (`ID`) 
) 
相關問題