将回复表与故障单表相关联

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成为clustering密钥的良好候选者。 ²
• 避免FK ³ 的附加索引，因为主索引涵盖两个字段 ⁴ 。每个额外的索引都会占用空间和性能（修改数据时）。
• 将父PK传播到表层次结构 ¹ ，其中：
  • 可以让你避免一些加入。
  • 可能需要正确建模某些类型的diamond-shaped dependencies。

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

---

¹ 在您的案例中尚未（尚）相关，因为您（还）没有任何引用Reply的表格。

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

³ 在从Ticket删除或修改行时，有效实施参照完整性是必要的。

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