添加（或不添加）FK以使SELECT更简单

Question

我正在开发Android应用程序和JSON Web服务。 Android应用程序将使用这些Web服务。

另外，我将在双方都有一个数据库，服务器端和客户端将具有相同的数据库架构。

我将解释我正在尝试做什么：

• 用户创建一个 EReport 或更多。
• 每个 EReport 都有一个 QAP 。 QAP 表将是一份副本 服务器端数据库。
• 每个 QAP 都有一个或多个缺陷。 缺陷将是副本 服务器端数据库。
• 如果用户需要，可以定义缺陷。要做到这一点，我有 添加了 EReportDefect 表。
• 缺陷可能包含一张或多张照片。我创造 EReportDefImg 用于存储EReport和EReportDefect与一个或多个图像之间的关系。

我的问题是： EReportDefImg 我需要 eReportId 作为FK吗？

我添加了该列，因为我可以用来查找EReport的所有缺陷图像。

Answer 1

人类逻辑说，如果有报告缺陷，必须有报告。所以使用FK。我想这可能会对你有所帮助。

Answer 2

  

我是否需要在EReportDefImg上将eReportId作为FK？

没有

EReportDefImg.eReportId允许EReportDefImg行引用EReportDefect行，EReportDefect.eReportId与EReportDefImg.eReportId不同。

  

我添加了该列，因为我可以用来查找EReport的所有缺陷图像。

您仍然可以通过加入EReportDefImg.eReportId和EReportDefImg来获取EReportDefect来完成该操作（不EReportDefect.eReportId}。

如果你想避免加入，你可以使用识别关系在eReportId的PK中包含EReportDefect，然后将其迁移到EReportDefImg.eReportId（然后你可以直接用于过滤，而不用JOIN）。同上defectId。

注意：我添加了eReportDefectNo以允许多个EReportDefect用于EReport和Defect的相同组合。如果不需要，请删除eReportDefectNo。

---

顺便提一下，您的模型可以通过EReportDefect将单个QAP连接到两个不同的EReport（一个到Defect，另一个到{{1}} ）。这是故意的吗？

Answer 3

不，你不会，这种设计通常是出于性能原因而执行的 - 省略了不必要的连接。如果你没有遇到这样的问题，请不要这样做。

顺便说一句，你似乎把太多外键放入主键。这样做是为了帮助维护数据的一致性，但由于性能下降，这通常不是一个好的做法。

顺便说一下。 EReportDefect中的defectId外键是什么？