mysql：设计实践

Question

我有这样的表格设置：
一条消息被发送给一组用户。

此消息放入 parent_message 表
该表包含 id |发件人 ID | date

该组中发送的每条消息都会放入 child_message 表中
该表包含 id |父 ID |留言 | date_sent

收到回复后，会将其放入 reply_message 表
该表包含 id |儿童 ID |留言 |接收日期。

现在我对这个设置有几个问题。

---

1) Every time the page is loaded I need to show how many child messages each parent message has.
Would you add a column to the parent_message table called child_count or work it out in your query.
why, why not?

示例查询

select *, 
count(select parent_id from child_message c where c.parent_id = p.parent_id ) child_count 
from parent_message;

2) 如果用户选择，他们可以查看父消息的所有回复消息。
您会将parent_id 添加到回复reply_message 表中还是在查询中计算出来？
为什么，为什么不呢？

示例查询

select * from reply_message 
where child_id in(select id from child_message where parent_id = '66')

Answer 1

我想说这很大程度上取决于消息的数量。如果系统中有大约一百万条消息，则连接到 child_message 可能会变得非常昂贵。在这种情况下，向父表添加 child_count 可能有利于您的性能。您的第二个用例也是如此。当然，这是对数据的某种非规范化，因此如果您的系统允许重塑主题和回复（例如拆分主题），那么在这种情况下您必须进行额外的簿记。

另一种方法是创建索引表，它保存您需要的信息并以异步方式离线更新它们，如果您不需要信息始终 100% 准确，例如

表 message_counts (parent_id, child_count)

然后安排当新消息添加到系统时，例如通过使用触发器，对这些进行更新。

因此，底线是，除非遇到性能问题，否则请保持表正常化，就像它们本来的样子一样。当您预计有数百万条消息和回复时，一些非规范化可以帮助加快速度。索引表可以帮助离线创建聚合统计信息，除非您需要它们准确且最新。

Answer 2

在这两种情况下，您可能最好都解决它，但我会重写查询

SELECT 
   p.*
   count(child.*) childCount
FROM 
   parent_message p
   LEFT JOIN  child_message  c
   on c.parent_id = p.parent_id

，并且

SELECT DISTINCT
       rm.*
    FROM 
        reply_message rm
        INNER JOIN child_message  cm
        rm.child_id = cm.id 
   WHERE
       parent_id = '66'

还会列出字段，而不是执行 SELECT *