Question

我正在尝试构建一个为多个用户存储消息的数据库。每个用户将能够发送/接收5种不同的消息“类型”（严格地说是标签，实际数据类型将是相同的）。我最初的想法是为每个用户创建多个表，代表5种不同的消息类型。我很快就知道这不是一个好主意。我的下一个想法是为每个消息类型创建一个带有用户列的表，但从性能角度来看，我不确定这是最好的方法。如果用户1发送100个消息类型1，而用户3仅发送10个消息，会发生什么？剩下的字段将是空值，我真的不确定这是否有所不同。思考？建议和/或建议阅读？提前谢谢！

Answer 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%子句）发送发送的所有邮件非常容易，将发送给某人（{{1} }），某种特定类型（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子句获取单个类型的所有消息。但即使这样一个简单的任务，如获取一种特定的消息，也不是那么容易：你必须检查这5列中的每个，直到找到{{1}的那一列。价值。

类似的困难期望那个试图计算每种类型的消息数量的人（这与上面给出的结构几乎是微不足道的：WHERE is_msg_type_1 = 1。

所以请不要这样做。）除非你有充分的理由不这样做，否则试着对你的桌子进行构造，这样随着时间的推移，它们的高度会增加 - 而不是宽度。

Answer 2

其余字段为空值

除非您是垂直设计数据库，否则不会有剩余的字段。

user   int
msgid  int
msg    text

Answer 3

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`)
 )

数据库设计：每个用户多个表

3 个答案: