我记得在播客014中听到Joel Spolsky提到他几乎从未使用过外键(如果我没记错的话)。然而,对我来说,它们对于避免数据库中的重复和后续数据完整性问题非常重要。
人们是否有一些可靠的理由(以避免与Stack Overflow原则一致的讨论)?
编辑:“我还没有创建外键的理由,所以这可能是我真正建立一个外键的第一个理由。”
我记得在播客014中听到Joel Spolsky提到他几乎从未使用过外键(如果我没记错的话)。然而,对我来说,它们对于避免数据库中的重复和后续数据完整性问题非常重要。
人们是否有一些可靠的理由(以避免与Stack Overflow原则一致的讨论)?
编辑:“我还没有创建外键的理由,所以这可能是我真正建立一个外键的第一个理由。”
当前回答
在我参与的一个项目中,经常存在隐式关系而不是显式关系,这样可以在同一列上连接多个表。
请看下面的表格
地址
AddressId (PK) EntityId EntityType 城市 状态 国家 等。
EntityType的值可能是Employee、Company、Customer, EntityId指的是您感兴趣的表的主键。
我真的不认为这是最好的方法,但它对这个项目有效。
其他回答
我经常使用它们,但后来我为金融系统制作数据库。数据库是应用程序的关键部分。如果金融数据库中的数据不是完全准确的,那么无论你在代码/前端设计上投入多少精力都没有意义。你只是在浪费时间。
还有一个事实是,多个系统通常需要直接与数据库接口-从其他系统只是读取数据(Crystal Reports)到系统插入数据(不一定使用我设计的API;它可能是由一个刚刚发现VBScript并拥有SQL框SA密码的愚蠢的经理编写的)。如果数据库不能像白痴一样证明它可能是,好吧,再见数据库。
如果您的数据很重要,那么可以使用外键,创建一套存储过程来与数据交互,并创建最强大的DB。如果您的数据不重要,那么为什么要开始创建数据库呢?
它们会使删除记录变得更加麻烦——当其他表中存在外键违反约束的记录时,您就不能删除“主”记录。可以使用触发器进行级联删除。
如果不明智地选择主键,则更改该值将变得更加复杂。例如,如果我有我的“客户”表的PK作为人的名字,并使该键在“订单”表中为FK,如果客户想更改他的名字,那么这是一个巨大的痛苦……但这只是粗制滥造的数据库设计。
我相信使用火密钥的优点大于任何假定的缺点。
外键对于任何关系数据库模型都是必不可少的。
像许多事情一样,这是一种权衡。这是一个你想在哪里进行验证数据完整性的工作的问题:
(1)使用外键(单点配置为一个表,功能已经实现,经过测试,证明有效)
(2)把它留给数据库的用户(可能多个用户/应用程序更新同一个表),这意味着更多潜在的故障点和测试的复杂性)。
数据库执行(2)更有效,使用(1)更容易维护,风险更小。
验证外键约束需要一些CPU时间,因此有些人省略外键以获得额外的性能。