数据库建模：Facebook 之类的消息

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 是“wall”，则 types_id 等于第一个表的“ wall_owner_profile_id”。例如，如果 type 为“media”，则 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

首先，对一些小问题进行回应，以帮助您走上关系数据库和数据库设计的笔直而狭窄的道路。

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

2. 向子表插入行的要求（非约定）是父行必须首先存在。这就是 FK 约束的作用，它确保父行存在。在多对多表中，在插入子表（具有两个 FK，每个父表一个）之前，两个父行都必须存在。

3. types_id 是一个可怕的想法，因为你破坏了设计规则，并消除了 RI 的可能性。最好使用带有 RI 的单独列（对每个父项的 FK 约束）。 （但是还有更好的方法。）

4. 所有 Id 列（PK）都应重命名为 TableId。每个都应该有同名的私有数据类型。列名无论存在于何处都将保持不变，作为 FK。唯一的例外是同一个父表有两个 FK：应该是 RoleTableId。

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

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

1. 您的单个​​消息表已经完成了一半。您已经直观地将两个表规范化为一个表。但还有一些问题需要解决，所以让我们来处理它们。

   • Sebastian 提供了两个多对多表，所以我不再重复。
     .

2. 在您决定这是最终的（因此两个多对多表是最终的）之前，我建议您标准化 Wall 和 Media。对我来说，看起来有很多常见的列。如果将其标准化，您将得到一张表。由于它是由Person为了邀请消息而公开或提供的Thing，并且类型可以是{ Photo |专辑 |邮箱| Wall }，我将其称为 PersonFurniture 或 PersonObject。

   • 如果最终形成一张表，那么您就不需要两张多对多的表，只需要一张表。

对评论的回复

1. 绘制模型比输入长篇讨论更容易、更快捷。我已经考虑过你的大部分问题。请检查此内容并就您不明白的任何问题提出具体问题。

链接到社交网络数据模型（第 3 页）

IDEF1X 符号链接。

• 选择您自己的表和列名称
• Message.Subject 可以设置为 CHAR(0) 或忽略（如果不是 Email）。
• wall_message 和 email_message 相同不是问题，我已将它们规范化到一个表中，
• 无论它是 wall_message code> 或 email_message 或 media_message 是“发送”到哪里的问题，对吗？您可以通过 CHECK 约束轻松禁止任何消息类型的任何功能（例如分组）。
• 您还没有回答上面的 (2)
• 我认为消息分组与媒体分组不同：想想相册上何时有消息列表。
• 一切都不是问题，建模的整个理念就是，纸张很便宜；关系数据库的整体思想是，尽可能多地使用约束、检查和规则。如果有什么问题我们可以改变它。

（您的种族问题中想要种族（3 个级别）还是 2 个级别？）

Answer 2

您可以拥有表消息，然后是 n:m 关系表，即

message_to_wall:
- messageID
- wallID

message_to_media:
- messageID
- mediaID

这样您可以保持引用完整性并且只有一个消息表。

当然，从技术上讲，这将允许它将消息发布到墙上和媒体项目（照片等）上。所以你不能轻易限制这一点。

否则 - 如果您并不真正需要关系数据库，您可以考虑使用 NoSQL 数据库，例如 CouchDB 或 MongoDB。您可以将所有这些评论存储在墙上或媒体文档上。这样，您就不需要所有必需的 JOIN 查询，并且评论都链接到媒体或墙。