组合或分离表：文件和消息？

Question

这是为了在我的客户和我之间在线共享文件而设计此表的最佳方法，还是应该将 Message 表和 File 表分开或将它们组合在一起？

组合表方式： FILE表

• ID
• 顾客ID
• FilePath（来自双方的文件路径：客户和我）
• 内容（消息）
• 标记（已读/未读 + ISent/CustomerSent）
• 状态（已查看、已审核、已接受等）
• 时间戳（文件的当前日期时间已更改）
• CreationDate（创建文件的日期）
• Dateline（设置文件对应动作的截止日期）

优点：1张单人桌

缺点：共享同一个表的 2 个操作，在每条记录中，“FilePath”或“Content”可以为空，以防客户希望通过编写消息而没有附件 (FilePath) 或客户上传任何文件而没有任何消息（内容）写的。

2 表方法：

文件表

• ID
• 顾客ID
• 姓名
• 类型
• 尺寸
• 数据
• 已创建

留言表

• ID
• 顾客ID
• 信息
• 依恋
• 已创建

优点：没有空字段

缺点：它们在这两个表中的用途相同，但一个侧重于消息，其他侧重于文件。

你会推荐什么？

Answer 1

我肯定会用两张单独的桌子。

客户希望通过在没有附件 (FilePath) 的情况下编写消息来进行通信，或者客户在没有编写任何消息 (Content) 的情况下上传任何文件。

但是按照您现在建模的方式，文件和消息之间确实没有任何关系，因为它们都依赖于 Customer_ID。如果您尝试查询每个客户的所有文件和消息，您将无法判断两者何时相关（除非通过查看日期）。

听起来客户可以拥有一个没有消息的文件（反之亦然）。我认为创建一个“通信”表更有意义（因为没有更好的词）。从本质上讲，它允许您为您的客户跟踪所有类型的通信（消息和文件），还可以在适当的时候将消息与文件（附件）联系起来。

table: Communication
communication_id   int
customer_id        int
created            datetime

这将允许您通过从文件和消息表中取出“created”和“customer_id”来进一步规范化。同样，您希望将“communication_id”添加到文件和消息中。然后要报告它们，您可以执行以下操作：

SELECT *
FROM Customer cu
INNER JOIN Communication co ON cu.customer_id = co.customer_id
LEFT JOIN File f ON f.communication_id = co.communication_id
LEFT JOIN Message m ON m.communication_id = co.communication_id
ORDER BY cu.customer_id, co.communication_id