问MySQL -FK在网络应用程序中有用/可行吗？

EN

外部密钥是您和数据完整性问题之间的一个有用的障碍。他们告诉数据库代表您做额外的工作，以确保您定义的完整性被强制执行，不管一些应用程序代码有多么糟糕。这在他们的职业生涯中至少挽救了每个DB程序员的脖子。你绝对应该在你的模型中设计外键，特别是当你认为你不需要外键的时候。

也就是说，如果您在数据库层上限制可伸缩性，那么FKs可能会被关闭，因为理论上说，FKs是在重复您的应用程序已经在做的工作(也就是说，您的应用程序不应该被编码成蓄意破坏关系完整性的事情，如果不是FKs的话)。这并不是针对心灰意冷的人，因此并不总是性能上的胜利(一些联接更有效率，因为DB知道某些关系是否可以产生行)。

与所有优化一样，规则1是“不要做它”，第2条规则是“不要做它(还)”。确保如果你要沿着这条路走：

1)您有一个特定的性能负载数据来支持您的决定

2)您有能力用开关打开或关闭它们(即不要删除它们并丢弃代码，而且绝对不要忽略设计它们)。

3)您有能力定期验证您设计的完整性约束是否被应用程序代码正确地强制执行(例如，一项夜间作业，它验证没有孤儿)。

外键将确保表order_details中包含引用orders表的字段order_id的行永远不会有不存在于orders表中的order_id值。

外键不需要有一个工作的关系数据库，但它们绝对是必要的，以避免破裂的关系和孤儿行(即。参考完整性)。酸中的C必须具备在数据库级别强制执行引用完整性的能力。

至于您对性能的关注，一般来说，性能的影响(如果有的话)可以忽略不计。我建议把你所有的外键约束，只有当你有真正的性能问题，你无法解决的情况下，没有它们的实验。

此外，作为附带说明，虽然与MySQL没有直接关系，但这是Microsoft模式和实践:第14章改进Server性能的引文。

当主键和外键被定义为数据库架构中的约束时，服务器可以使用这些信息创建最佳执行计划。

保存您的外键-它确保，无论您有什么木偶为您编写代码，您的数据保持在一种可用的和预期的格式。除非你看到的是大量的流量，否则我甚至不会考虑移除它们。