2013-06-03 52 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`) 
) 
相关问题