0

我有以下数据库设计：

在此处输入图像描述

一个E-Report有一个QAP有一些Requirements。AQAP和它Requirement的 s 可以用在一个以上E-Report。

每个Requirement人都会在每个电子报告中确认是/否。我添加EReportReq了存储需求确认值（用户将设置这些值）。

而且，Requirement每个. 将存储和关系。ImageE-ReportEReportReqImgImageRequirement

如果您需要有关此数据库模型的更多详细信息，请告诉我。

我的问题是关于EReportReq桌子的。我不确定是否需要一列作为主键 ( EReportReqId) 或者我可以使用eReportIdandrequirementId作为主键。

如果我使用这两列，eReportId并且requirementId作为主键，我需要将这两列添加到EReportReqImg表中，所以我不知道这种方法是否比我的更好。

你怎么看？

4

2 回答 2

2

我的问题是关于EReportReq桌子的。我不确定是否需要一列作为主键 ( EReportReqId) 或者我可以使用eReportIdandrequirementId作为主键。

您可以使用它们中的任何一个 - 它们都不是绝对“更好”的。请注意，如果您决定使用第一种方法，还要在{eReportId, requirementId}.

第一种方法（使用非识别关系和代理键）导致：

  • 子表中的“更精简”外键（EReportReqImg在这种情况下） - 正如您已经注意到的，
  • 级联 ON UPDATE 不会传播给子级（因此，如果您 update EReport.eReportId，只有EReportReq.eReportId级联更新，但不是EReportReqImg.eReportId）
  • 并且可以对 ORM 更加友好。

另一方面，第二种方法（识别关系和自然键）：

  • 对 JOIN 的需求可能会减少（例如，您不需要EReportReqImg JOIN EReportReq仅仅找出requirementId- 您直接在 中拥有它EReportReqImg.requirementId），
  • 更适合聚簇表（例如EReportReq，具有相同的eReportId行将在物理上“关闭”存储，这可能对某些查询有很大好处）
  • 避免代理键上的附加索引。

由于您有少量子表，因此“胖”FK 并不重要，而且由于我们正在处理 ID，它们不太可能更改并且级联 ON UPDATE 不太可能成为问题。所以，我的直觉是采用第二种方法，但您可能还有其他一些考虑因素可能会使您的决定朝着不同的方向倾斜……

于 2012-06-27T16:08:03.860 回答
0

让我们从这个状态开始：

我需要将这两个添加到 EReportReqImg

通常将 2 FK 用作 PK 是不可更改数据的正常做法。因此，如果EReportReq不应该以将其拖动到另一个requirementId或eReportId然后使用复合键的方式进行更改。否则，使用单值主键更加健壮和高效 - 因为它在此期间不会更改，因此您不需要编写触发器或使用棘手的级联来更新子表。

其他要查看的选项是结果 SQL 的简单性，简单胜于复杂- 使用 2 个字段编写INNER JOIN是复杂的构造，并且可能存在遗漏其中一个键的错误位置。

于 2012-06-27T16:05:19.293 回答