database - 将回复表关联到工单表

Question

假设我有一张票/问题可以有零个或多个回复。

我可以通过两种方式关联“回复”和“票证”表。

第一种方法：

Ticket(**ticket_id**, title, message) //ticket_id: PK
Reply(**reply_id**, reply_message, ticket_id) //reply_id: PK and ticket_id: FK

第二种方法：

Ticket(**ticket_id**, title, message) //ticket_id: PK
Reply(**reply_id**, **ticket_id**, reply_message) //reply_id: PK and ticket_id: FK & PK

在我看来，两者都是正确的。

如我所见，第二种方法中的回复被认为是弱实体，因为回复与票证密切相关。但是，我更喜欢第一种方法，因为它在编程级别更容易处理；在第一种方法中，我们只需要处理一个 PK。你同意吗？为什么和为什么不？.

注意：票证和回复是模型样本。

Answer 1

正如我所看到的，第二种方法中的回复被认为是弱实体......

正确的。

...因为回复与票证密切相关。

不知道你的意思是什么。它很弱，因为如果没有从父级迁移的属性，就无法识别它。

但是，我更喜欢第一种方法，因为它在编程级别更容易处理；在第一种方法中，我们只需要处理一个 PK。你同意吗？为什么和为什么不？

这得看情况 ;）

强实体和非识别关系（您的“第一种方法”）：

• 可能对客户端代码更友好，特别是如果您使用 ORM。
• 防止父 PK 进一步向下传播表层次结构¹，其中：
  • 将使儿童 FK 更瘦。
  • 将“切断” ON UPDATE CASCADE 并防止它进一步向下传播到表层次结构。

弱实体和识别关系（你的“第二种方法”）：

• 生成的 PK 是聚类键的良好候选者。²
• ^{避免在 FK 3}上附加索引，因为主索引涵盖两个字段⁴。每个额外的索引都会消耗空间和性能（修改数据时）。
• 沿表层次结构¹传播父 PK ，其中：
  • 可以让你避免一些 JOIN。
  • 对于正确建模某些类型的菱形依赖项可能是必需的。

总而言之，这两种解决方案都不是绝对“更好”的——这是选择正确平衡的问题。

---

¹与您的情况无关（尚），因为您（尚）没有任何引用Reply.

²许多（但不是全部）DBMS 只允许在 PK 上进行集群。在您的情况下，集群{ticket_id, reply_id}（注意字段的顺序）会将所有连接到物理上靠近的相同勾选的回复存储在一起，从而显着减少某些类型的查询的 I/O。

³在从Ticket.

⁴假设您将订单更改为{ticket_id, reply_id}。