mysql - 数据库建模 : Facebook like messages

Question

我正在尝试模仿类似于 FB 的东西。基本上，用户可以在用户个人资料的各个部分(例如“墙”、“照片”等)发表评论。我认为以下模型会起作用:

===========================
wall_message
===========================
- id (PK)
- parent_id (FK)
- wall_owner_profile_id (FK, identify whose wall the message is for)
- poster_profile_id (FK)
- message
- timestamp

===========================
media_message
===========================
- id (PK)
- parent_id (FK)
- media_id (FK, identify which photo, video, etc.)
- poster_profile_id (FK)
- message
- timestamp

parent_id允许将消息“分组”到相关讨论中。第一条消息的parent_id将为 0，后续消息的 PK 将是 parent_id值(创建父子关系)。
poster_profile_id标识发布消息的人。

以上两个表非常相似。将它们结合起来会不会是个好主意，例如:

===========================
message
===========================
- id (PK)
- parent_id (FK)
- type (ENUM: "wall", "media", etc.)
- types_id (FK, see explanation below)
- poster_profile_id (FK)
- message
- timestamp

在这种情况下，如果说 type是“墙”，然后 types_id等于第一个表的“wall_owner_profile_id”。如果说，type是“媒体”，然后 types_id等于第二个表的 media_id .

我有点担心第二种方法需要一列来解释另一列的含义。我想，这样做的一个缺点是，types_id 没有参照完整性(与“wall_owner_profile_id”和“media_id”不同)。

解决这个问题的最佳方法是什么？

编辑 1:

到目前为止，这似乎是解决方案:

===========================
message
===========================
- message_id (PK)
- parent_message_id (FK)
- profile_id (FK, referring to who posted the message)
- message
- subject (applicable only for emails)
- timestamp

===========================
wall_message
===========================
- message_id (FK)
- profile_id (FK, referring to who received the message/owner of wall)

===========================
media_message
===========================
- message_id (FK)
- media_id (FK)

===========================
email_message
===========================
- message_id (FK)
- profile_id (FK, referring to who received the message)

Answer 1

首先，对小点的一些回应，让你走在关系数据库和数据库设计的直线和狭窄的道路上。

整个想法是将尽可能多的规则放在数据库中的一个地方，而不是代码中。几乎所有的事情都可以通过 DDL 来完成:FK 约束； CHECK约束；和 RULES (所有 ISO/IEC/ANSI SQL 要求)。然后所有用户(您的应用程序是用户)可以看到所有规则并更好地理解数据库。无论使用什么客户端来执行代码，这都可以保护数据库。这些约束的数据库供应商(即商业的，而不是免费的)实现比代码更可靠。

将行插入子表的要求(非约定)是父行必须首先存在。这就是 FK 约束所做的，它确保父行存在。在多对多表中，两个父行必须存在才能插入子行(有两个 FK，每个父行一个)。

types_id这是一个可怕的想法，因为您违反了设计规则，并消除了 RI 的可能性。最好有带有 RI 的单独列(对每个父级的 FK 约束)。 (但还有更好的方法。)

所有您的 Id列，PK，应该重命名 TableId .每个都应该有同名的私有(private)数据类型。列名在它存在的任何地方都保持不变，作为 FK。唯一的异常(exception)是同一个父表有两个 FK:它应该是 RoleTableId .

解决这个问题的最佳方法是什么？

正常化。并且您将遇到需要解决的问题。因此再次归一化。并继续这样做，直到您没有要解决的问题为止。

您的单个 Message 表已经完成了一半。您已经直观地将两个表归一化为一个。但是有问题需要解决，所以让我们处理它们。

Sebastian 已经提供了两张多对多表，所以我就不重复了。
.

在你决定这是最终的(因此两个多对多表是最终的)之前，我建议你规范化 Wall和 Media .对我来说，看起来有很多常见的列。如果您将其标准化，您将得到一张 table 。因为它是由 Person 暴露或提供的东西以邀请为目的Messages , 类型可以是 { Photo | Album | Mailbox | Wall } ，我会称之为 PersonFurniture或 PersonObject .

如果最终变成一张 table ，那么您将不需要两张多对多 table ，只需一张。

回复评论

绘制模型比输入长时间的讨论更容易、更快捷。你的大部分问题我都想过。请检查这一点，并就您不理解的任何内容提出具体问题。

Link to Social Network Data Model (第 3 页)

Link to IDEF1X Notation对于那些不熟悉关系建模标准的人。

选择您自己的表名和列名

Message.Subject可以设置为 CHAR(0)或忽略，如果它不是电子邮件。

那个wall_message和 email_message相同不是问题，我已将它们标准化为一张表

是否是wall_message或 email_message或 media_message是“发送”到哪里的问题，对吗？您可以通过 CHECK 约束轻松禁止任何消息类型的任何功能(例如分组)。

您还没有回答上面的(2)

我认为消息分组与媒体分组不同:想想什么时候相册上有消息列表。

没有什么是问题，建模的整个想法是，纸很便宜； Relational dbs 的整个想法是，尽可能多地使用约束、检查、规则。如果有任何问题，我们可以更改它。

(您的种族问题是要种族(3 个级别)还是 2 个级别？)