私人消息数据库设计 [英] private message database design

问题描述

我正在创建一个简单的私人消息系统，不确定哪个数据库设计更好。

I'm creating a simple private message system and I'm no sure which database design is better.

第一个设计是用于消息的表，邮件注释表：

The first design is a table for messages, and a table for message comments:

Message
---------------
id
recipientId
senderId
title
body
created_at

MessageComment
---------------
id
messageId
senderId
body
created_at

第二种设计，是一个用于消息和注释的表，还有一个附加字段 messageId ，因此我可以进行链接消息作为注释。

the second design, is one table for both messages and comments, and an addition field messageId so i'll be able to chain messages as comments.

Message
---------------
id
recipientId
senderId
messageId
title
body
created_at

我想听听您的意见！

推荐答案

我会为一张表投票。

通常，只要两张表中的数据相同或非常小类似的事物和它们所代表的逻辑概念密切相关，我将它们放在一个表中。如果数据中有很多差异，或者概念确实不同，那么我将它们做成两个表。

In general, whenever the data in two tables is the same or very similar and the logical concepts they represent are closely related, I'd put them in a single table. If there are lots of differences in the data or the concepts are really different, I'd make them two tables.

如果您创建了两个表，并且发现自己经常写作

If you make two tables and you find yourself regularly writing queries that do a union of the two, that's an indication that they should be combined.

如果您创建了一个表，但发现有很多字段始终为null，则表示它们应该合并。案例A和案例B始终为空的其他字段，或者如果您给字段赋予尴尬的双重含义，例如对于类型A，此字段是邮政编码，但对于类型B，则是产品序列号，即表示应该将其拆开。

If you make one table but you find there are many fields that are always null for case A and other fields that are always null for case B, or if you're giving awkward double-meanings to fields, like "for type A this field is the zip code but for type B it's the product serial number", that's an indication they should be broken out.

这篇关于私人消息数据库设计的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！