我在过去的经历中已经看到，大多数人不会在表格中使用物理关系，他们会尝试记住它们并仅通过编码来应用它们。
此处'物理关系'指的是主键，外键，检查约束等< / p>
在设计数据库时，人们会尝试在纸上标准化数据库，并记录下来。就像，如果我必须为营销公司创建一个数据库，我会尝试了解它的要求。 例如，哪些字段是必填字段，哪些字段仅包含（a或b或c）等。
当所有事情都清楚的时候，为什么大多数人都害怕受到约束？
您认为的原因是什么？
答案 0 :(得分：4)
我总是让DBMS强制执行主键和外键约束;我经常添加检查约束。就我而言，数据太重要了，不存在存储不准确数据的风险。
如果您将数据库视为一系列存储的真正逻辑命题，您将看到如果数据库包含错误命题 - 错误 - 那么您可以争论任何您想要的结论。鉴于错误的前提，任何结论都是正确的。
为什么其他人不使用PK和FK约束等？
有些人并不知道它们的重要性（因此缺乏知识肯定是一个因素，甚至是一个主要因素）。其他人担心他们的性能会花费太多，忘记必须修复的一个错误可能会因为没有让DBMS为您进行检查而节省了所有时间。我认为如果当前的DBMS无法很好地处理它们，那么可能（可能）是时候更改DBMS了。
答案 1 :(得分：1)
许多开发人员在实际执行操作之前会检查数据库上方代码中的约束。有时，这是由用户体验考虑因素驱动的（我们不希望向无法保存到数据库的用户提供选项/选项）。在其他情况下，它可能由与执行声明相关的痛苦，确定失败的原因，然后采取纠正措施。大多数人会认为代码更易于维护，如果它事先进行检查，以及可能正在发挥作用的其他业务逻辑，而不是通过异常处理程序采取纠正措施。 （并不是说这必然是一个理想的思路，但它是一个普遍的思路。）无论如何，如果你在发表声明之前进行检查，而不是特别意识到数据库可能会被触及的事实对于未通过完整性执行代码进入的应用程序/用户，您可能会得出结论，数据库约束是不必要的，尤其是在使用它们可能产生的性能损失时。此外，如果要检查数据库上方的应用程序代码中的完整性，可能会认为它违反DRY（不要重复自己）在数据库本身中实现逻辑上等效的检查。如果不仔细管理，完整性规则的两种表现形式（数据库约束条件和数据库上方的应用程序代码中的表现形式）原则上可能会失去同步。
另外，我不打算忽略选项2，许多开发人员对数据库约束不太了解。
答案 2 :(得分：0)
嗯，我的意思是，我认为每个人都有权获得自己的意见和发展策略，但在我看来，这些人几乎肯定是错的：）
然而，有人可能希望避免限制的原因是效率。不是因为约束很慢，而是因为存储冗余数据（即缓存）是加速（好，避免）昂贵计算的一种非常有效的方法。这是一种可接受的方法，如果正确实施（即缓存以常规/适当的间隔更新，通常我会使用触发器进行更新）。
至于没有缓存动机而不是我们FK的动机，我无法想象。也许他们的目标是在他们的数据库结构中“灵活”。如果是这样，很好，但不要使用关系数据库，因为它没有意义。非关系数据库（OO dbs）当然有它们的位置，甚至可能更好（很有争议，但很有争议）但是使用关系数据库并且不使用它的核心属性是错误的。
答案 3 :(得分：0)
有几个原因导致关系不按重要性降序执行：
人性化的错误处理。 您的程序应检查约束并向用户发送可理解的消息。出于某种原因，普通人不喜欢“SQL表格中违反SQL异常代码-100013的规则”。
操作灵活性。 你不是真的想你的运营商试图找出哪些命令你必须在凌晨3点加载在你的表，你也不希望你的测试人员拉了头发因为他们不能将数据库恢复到起始位置。
< / LI>效率。 Cheking约束会消耗IO和CPU。
功能。 它是一种廉价的方式来保存细节以便以后恢复。例如，在一个在线订购系统上，你可以留在表中的详细条目行用户杀死父母订单时，如果他以后恢复了的细节重新出现，就好像一个奇迹的顺序 - 你acheive这个额外的功能删除代码行。 （当然，你需要一些家务管理程序，但这很简单！）
答案 4 :(得分：0)
我总是会定义PK和FK约束。特别是在使用ORM时。它真的让每个人都很容易让ORM对数据库进行逆向工程而不是手动配置它来使用一些PK和FK
答案 5 :(得分：0)
随着事情变得越来越复杂，数据库中需要更多的表和关系，您如何确保数据库开发人员记得检查所有这些？当您更改添加新“非正式”关系的架构时，如何确保可能受影响的所有应用程序代码都发生更改？
突然之间，您可能会删除应该保留的记录，因为它们具有开发人员在写入删除过程时忘记检查的相关数据，或者因为在将最后十个相关表添加到架构之前该过程已到位。
没有正式建立PK / FK关系，这是极端的蛮干事。我处理从许多不同供应商和数据库收到的数据。您可以确定哪些数据完整性问题最有可能是由于未能通过数据质量差来明确定义关系而导致的。