MySQL-FK在Web应用程序中是否有用/可行?

外键是您和数据完整性问题之间的一个有用屏障。它们告诉数据库为您做额外的工作,以确保您定义的完整性得到强制执行,不管某些应用程序代码有多糟糕。在他们的职业生涯中,这至少为每个数据库程序员节省了一次时间。你应该在你的模型中设计外键, 尤其地 如果你认为你不需要它们。

也就是说,如果您在数据库层上推行可伸缩性的限制,那么FK可能是您关闭的东西,因为 理论上 ,它们正在做你的应用程序已经做过的重复工作(也就是说,你的应用程序不应该被编码为故意做一些会破坏关系完整性的事情,如果不是fks的话)。这不适合胆小的人,就这一点而言,这并不总是性能上的胜利(有些连接更有效,因为DB知道某些关系是否可以产生行)。

和所有优化一样,规则1是“不要这样做”,规则2是“不要这样做(还没有)”。如果你要走这条路:

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

2)您可以使用开关打开或关闭它们(即不要删除它们并丢弃代码,而且绝对不要一开始就忽略了设计它们)。

3)您有一些能力定期验证您设计的完整性约束是否被应用程序代码正确地实施(例如,验证没有孤立项的夜间作业)。

Foreign keys 保证表中有一行 order_details 用一块地 order_id 引用一个 orders 桌子永远不会有 订单号 不存在于 命令 表。

外键不需要有一个有效的关系数据库,但对于避免断开的关系和孤立的行来说,它们绝对是必不可少的(即。 referential integrity )在数据库级别强制引用完整性的能力对于 C 在里面 ACID 站起来。

至于您对性能的关注,一般来说,性能的影响(如果有的话)是可以忽略的。我建议您加入所有的外键约束,并且只有当您有真正的性能问题而不能解决时,才能在没有这些约束的情况下进行实验。

另外,作为旁注,虽然与MySQL没有直接关系,但这是引用自 Microsoft Patterns and Practices: Chapter 14 Improving SQL Server Performance :

当主键和外键 定义为数据库中的约束 模式,服务器可以使用 创建最佳信息的信息 执行计划。

保留您的外键-它确保,无论您为您编写了什么muppet代码,您的数据都保持在可用和预期的格式。除非你看到的是严重的高流量,否则我甚至不会考虑移除它们。

Web应用程序与任何其他类型的应用程序都没有区别。当然,您可以从省略数据完整性检查中获得一个临界的加速,但这不会是一个 许多 价格太高了。

如果没有引用完整性,那么一旦得到一个悬空的外键(因为一些测试不正确的代码路径或部分更新失败*),许多依赖于该键指向某个对象的查询就会中断。这通常会使您的整个网站崩溃,直到您深入数据库并手动删除悬空的引用。

(*:除非您正在使用事务。但让我们面对现实吧,如果你是那种在没有参照完整性的情况下开发Web应用程序的作者,那么你也很难使用事务。)

除了这里提到的所有好的理由(实际上 不 不使用它们的原因),还有一个很好的原因:

外键记录了您的数据模型,使人们更容易理解它(这类似于cdonner提到的优势)。

将来,您的应用程序数据库中可能会有其他一些软件操作数据。例如:

• 从第三方系统导入批量数据
• 批量处理,需要大量的实时处理
• 等

通过使用外键,您将确保数据库的完整性得到维护,因为任何违反这些键的操作都将导致错误。

imho,性能提升(如果有的话??)不值得冒破坏数据库完整性的潜在风险。

外键都是关于完整性和功能性的,而不是性能的。如果您希望在两组列之间强制执行引用完整性,那么外键通常是最有效和最有效的方法。如果您不需要支持这样的完整性约束,那么显然性能问题不会出现。

外键可能通过支持某些类型的查询重写来提高性能,否则就不可能实现。然而,这主要是一个附加利益——一个确保约束被执行的副作用。

你的问题就像是说赛车不需要方向盘,因为它会减慢速度——胡说八道。所有的汽车都需要一个方向盘(至少是现在生产的汽车)。 其他人已经详细解释了为什么外键对数据完整性有用。 另外,我想指出的是,现代语言和框架可以使用数据库中的外键元数据来建立对象关系。LinqtoSQL做得非常优雅。当数据关系强制使用对象关系映射框架时,如果不定义外键,就无法真正使用该框架。