Ste*_*fen 37 sql sql-server database-design foreign-keys
我正在尽我所能说服我的老板让我们在我们的数据库中使用外键 - 到目前为止没有运气.
他声称这需要花费大量的性能,并说我们现在只需要有工作来清理无效的引用.
显然这在实践中不起作用,并且数据库充斥着无效的引用.
有没有人知道比较,基准或类似的证明使用外键没有显着的性能影响？(我希望能说服他)
HLG*_*GEM 38
插入,更新和删除的性能很小,因为必须检查FK.对于单个记录,除非你开始有一个与表相关联的荒谬数量的FK,否则这通常会非常轻微以至于不明显(显然,检查100个其他表需要更长的时间而不是2).这是一件好事并非坏事,因为没有完整性的数据库是不值得信任的,因而无用.你不应该以速度交换诚信.这种性能影响通常被优化执行计划的更好能力所抵消.
我们有一个中等大小的数据库,大约有900万条记录和FK到处应有,很少注意到性能损失(除了一个设计糟糕的表有超过100个外键,从这里删除记录有点慢)必须检查).几乎我所知道的每个dba谁处理大型的TB级数据库以及对大型数据集的高性能的真正需求都坚持外键约束,因为完整性是任何数据库的关键.如果具有TB级数据库的人能够承受非常小的性能损失,那么您也可以.
FK不会自动编入索引,如果它们未编入索引,则可能会导致性能问题.
老实说,我会拿一份你的数据库,添加正确索引的FK并显示插入,删除,更新和从这些表中选择的时间差,与没有FK的数据库中的相同.表明您不会造成性能损失.然后显示查询的结果,这些查询显示由于与其相关的PK不再存在而不再具有意义的孤立记录.对于包含财务信息的表格显示此信息尤为有效("我们有2700个订单,我们无法与客户关联"将使管理层坐下来注意).
Dan*_*llo 17
从Microsoft模式和实践:第14章提高SQL Server性能:
当主键和外键在数据库模式中定义为约束时,服务器可以使用该信息来创建最佳执行计划.
小智 6
这更像是一个政治问题,而不是技术问题.如果您的项目管理没有看到维护数据完整性的任何价值,那么您需要使用不同的项目.
如果你的老板不知道或不关心你有成千上万的无效引用,他就不会因为你告诉他这件事而开始关心.我同情这里的其他海报,他们试图通过打好这场斗争来敦促你做"正确的事",但我之前尝试了很多次,在实际操作中它没有用.大卫和歌利亚的故事很好,但在现实生活中,这是一个失败的主张.