评论系统数据库答案

【问题标题】：DB for Commenting System评论系统数据库
【发布时间】：2010-10-11 18:08:19
【问题描述】：

我想创建一个 2 级状态消息系统。创建表的最佳方法是什么？

范围：

用户设置状态消息
用户回复状态消息

这是一张显示它的图片

我创建的表格

用户（ID，名称....） status_messages (id, message, time, user_id) status_message_replies(id, message, time, status_message_id, user_d)

有人建议这可以用单个表格格式完成

status_messages (id, pid, message, time, user_id)

其中 pid = selfId 或 ParentId 的状态。

我想知道创建系统的最佳方法是什么？

【问题讨论】：

我不禁觉得我最近看到了类似的东西。 . .
朋友书？面子？类似的东西。

标签： mysql database database-design cakephp comments

【解决方案1】：

只要原始消息和响应具有相同的结构（属性集或列），您就可以使用单表方法。它的优点是您可以通过单个查询搜索原始消息和响应。

原始消息集可以在 pid = selfid 和响应中找到 pid selfid。如果能够分别查看原始消息和响应消息很重要（无需了解存储机制），您可以将上述条件封装在两个 VIEW 中：OriginalMessages 和 Responses。

如果原件和回复具有不同的属性（例如，如果您希望原件允许链接到 URL、照片等），您可以考虑使用两个单独的表格。但即使在那里，我也可能会主张使用一个单独的扩展表作为附加属性的表结构。这意味着您不必为那些不使用扩展属性的原始消息存储经常为空的列，并且您以后也可以轻松地将扩展属性添加到响应消息中（如果需要）。

【讨论】：

只要“空”列在表的末尾，你为什么要关心？
常识认为，某事物的模型不应包含不适用于某事物的属性。一种正常形式表明，在正常处理下，表中不应有包含 NULL 的单元格。性能考虑表明您不想存储不必要的列（甚至是 NULL）。在上面的示例中，您可以轻松地将扩展器表 OUTER JOIN 到 OriginalMessages 视图中，以提供包含所有列的原始消息的单一查询源，而无需额外的存储空间。
插入第一条记录时。我的意思是原始消息。我如何插入pid？因为我们不知道记录的 ID。我们在这里需要两个查询吗？如果不是这样，你能举个sql查询的例子吗？
@Harsha，您有多种选择，但在 MySQL 中，您最好的选择可能是发出 SELECT LAST_INSERT_ID();然后执行更新：UPDATE table SET pid = id WHERE id = %ValueFromLast_Insert_ID%;。您可能可以直接在 UPDATE 语句中使用 LAST_INSERT_ID()，我不确定。
我无法将内容从数据库中拉出。当我设置我想要 user_id = 1 的 StatusMessages 时。我只需要带有回复子数组的主要消息。我如何确保状态消息具有 id = pid 并且回复不包含具有 id = pid 的记录

【解决方案2】：

经典的 IS-A 关系：每个回复都是带有额外属性的消息（它是回复的消息）。这可能不是建模它的最佳方式。您将面临不得不对这两个表编写大量 UNION 查询的风险。

替代方案：

只有一张表：status_messages (id, message, time, status_message_id, user_id)，并允许 status_message_id 为 NULL
使用HAS-A：一张桌子status_messages (id, message, time, user_id)和一张桌子replies (reply_id, replies_to_id

前者的缺点是在 SQL 中使用 NULL 很棘手。当您想专门查询回复时，后者将需要连接。

顺便说一句，在它们所代表的关系之后命名列更清晰（IMO），而不是它们所引用的表。

【讨论】：

所以我可以使用这个 status_messages (id, pid, message, time, user_id)，其中状态的 pid 将是自我 id，如果它是回复，它将是父 id？
如果你这样做，你将如何识别回复？
Reiner：您不对原始消息使用 NULL，而是将父消息 ID 设置为等于消息的消息 ID。将自己“指向”自己为父母的消息是原始消息，在父母中具有不同值和“自我”id 的消息是回复。不需要 NULL，也不知道哪个是哪个。
@Larry，在 Facepage 的规模上，这些额外的值将增加额外的存储空间。如果有人认为使用 NULLS 很棘手，那么数据库可能不是最好的职业选择。
是的，这就是为什么我不建议存储它们。