关系数据库中的约束-为什么不完全删除它们？

如今，是否有任何理由在表之间（在SQLserver内部）建立约束？如果是这样，什么时候？我所在领域的大多数应用程序都是基于对象原理构建的，并且可以按需将表连接在一起。需求基于应用程序的需求。我不会加载一堆受约束的表来进行简单的查找，而这些查找又又（在执行操作之后）需要进行另一个简单的查找。

诸如EntityContext，Linq2Data，NHibernate之类的ORM工具也可以自己处理约束，至少您知道哪些表需要彼此使用。在服务器内部进行约束仅是对相同的更改进行两次（强制执行）？

通常这不是要决定的问题，但是此数据库的设计却大不相同。设计看起来很正常，主要是镜像应用程序使用的对象。令我困扰的是在SQLserver内部使用“非级联”配置的所有约束。这意味着在编码新的数据库查询时，您必须扮演“寻找并查找”的角色。在某些情况下，单个订单最多需要10个级别的确切订单。

这让我感到惊讶，我不确定如何处理。

在我的简单世界中，这种设置使约束失去了大部分目的。如果在不了解设计的情况下从主机访问数据库，则单击“确定”。

在这种情况下，您将如何行动？
为什么不从db中删除所有约束并将它们保持在应用程序级别呢？

不从DB中删除约束的两个一般原因：

• 现在或将来，可能会有更多应用程序使用或不使用ORM 来访问它。即使这些应用程序的开发人员忠实地复制了那里的所有约束（使用较低级别的非ORM解决方案可能会更加困难），但这始终是额外的工作。如果不是这样，即使是很小的疏忽也足以破坏架构的完整性 ……这是您不想冒险的事情。在大多数公司中，存储在数据库中的数据是其业务的命脉，因此，必须以任何方式确保其完整性。实现这一目标的久经考验的最佳方法是在数据库中实现尽可能多的约束。
• 查询优化器在很大程度上取决于数据库级别的约束。如果删除约束，查询性能可能会开始下降。您可能不会立即注意到它，但是有一天它会击中您，到那时可能已经太晚了，很难轻松修复它。事情的本质是，在峰值负载时间，数据库性能往往会崩溃，这是最不可能进行仔细，深思熟虑的设计改进，并辅之以精确的性能测量和详细分析以查明根本原因。

您的具体案例听起来像是DB模式可能最初是由ORM工具生成的（或由对关系领域不太有经验的人设计的），所以从关系的角度来看它不是最佳的。最好将其分析并改进为更“自然”的关系设计，同时使其与ORM视图保持一致。让数据库专家参与此分析可能会很有用。

应用程序可以来去去去，但数据永远存在。在我的公司中，DB已有30-40年的历史，只要公司存在，它就会一直存在。应用程序发生变化，开发人员来来往往。最好具有完整性和良好的逻辑数据模型。这样，某人可以查看数据并获得有意义的理解，而无需经历复杂的代码库。这也有助于显着报告。应用程序也可以并且会存在错误，并且数据库约束可以防止这种情况。我的默认位置是尽可能多地约束（FK和检查）。
没有约束的唯一原因是，如果您的设计模式不允许这样做，例如逐层表或性能问题。

令我困扰的是在SQLserver内部使用“非级联”配置的所有约束。

这不打扰我，这意味着有人表现出了良好的意识。级联删除通常对数据库非常不利。首先，如果您在相关表中有数据，有时您希望删除失败。例如，如果您有一个过去有订单的客户，则不希望删除该客户，或者丢失有关订单对象的数据，而级联删除操作将摆脱记录，这将使您的财务报告混乱。

您似乎认为轻松发展是最重要的。在数据库世界中，这根本不是事实。数据完整性是最重要的事情，其次是性能和数据安全性。如果编写查询需要更长的时间，那就这样吧。

通常，数据库由许多应用程序作用：一个或多个网站或桌面应用程序，报告应用程序，Web服务，查询窗口，ETL流程等。如果不在数据库级别强制实施约束，则首先会失去完整性数据，因为这些应用程序之一可能并不遵循所有规则。其次，如果您决定以后使用其他应用程序，则必须多次编码这些约束并重写它们。第三，您无法预先控制是否需要执行某种不会通过应用程序执行的数据维护任务（例如修复来自不良客户数据导入的数据或更改来自一个客户端的所有10,000,000条记录竞争对手收购该公司后将其转让给其他客户）。通常，应用程序开发人员不会

我在某处读到一个基本上说过的话：数据是您应用程序的关键。如果要通过你的UI永远只能访问数据（我的意思是有史以来，在现在和将来，为所有永恒...或者你的应用程序的生命周期，反正），那么你就不需要数据库的约束。但是，除了应用程序本身之外，还有可能需要触摸数据，例如Web服务，公共API，Rake Task / SQL Job / cron / automated script，那么您将为自己节省很多潜在的麻烦。通过保持数据库约束的方式。

我坚信这是软件开发的一个领域，你应该不适用DRY（我满以为downvotes的该语句一群）。您的数据是应用程序的核心和灵魂-如果数据一旦损坏就无法修复，那就结束了。IMO在所有需要的地方执行约束都是值得的。如果这意味着以数据库级别的触发器和约束，中间件上的服务器端验证以及UI上的客户端Javascript（针对Web应用程序）的形式出现，则IMO必须确保数据始终保持原始状态。

您知道ORM是什么意思吗？对象关系映射。引用维基百科“在不兼容的类型系统之间转换数据的技术”。是的，关系模型和对象模型不能一起使用。通过尊重两个类型系统的规则，ORM进行了很好的转换。RDBMS的组织方式使您可以通过使用约束来实现数据完整性。通常，完整性非常好，因此ORM在创建用于存储对象数据的数据模型时倾向于使用它们。您的ORM可能有充分的理由使用“非级联”约束。并且，如果这迫使您进行复杂的查询，而不仅仅是创建/更新/删除某些对象，则您的ORM设置有问题。

如果您认为关系概念很烦人，那么为什么不使用对象数据库呢？一段时间以前，它们运行缓慢（这就是为什么大多数人仍然使用RDBMS的原因），但是据我所知，情况有所改变。您将摆脱所有的关系壁垒。只是对象进入，对象离开。

嗯，这就是eBay所做的，他们可能拥有世界上最大的数据库之一：

http://www.dba-oracle.com/oracle_news/news_ebay_massive_oracle.htm http://www.addsimplicity.com/downloads/eBaySDForum2006-11-29.pdf

尽管上面已经说过通过引用完整性来提高性能，但是实际上它可能会降低；这就是为什么大型数据库一直放弃其约束并在应用程序层中进行工作的原因。据我所知，这是唯一真正的好理由。

通过消除这些约束，您实际上会失去安全网，从而保持数据干净，并带来自身的问题。因此，与所有事物一样，这是一种平衡行为。我认为总体上保持参照完整性是正确的选择。

在具有强大的引用完整性的开发环境中工作后，我知道从开发人员的角度来看，这可能会很痛苦。通常在开发环境中，脏数据并不重要，解决删除行的方法可能需要一个小时或更长时间。但是，它也非常有用，因为约束使架构变得明确。

首先-我的回答：不，您不应该仅依靠应用程序来管理数据。

这指向了一个更大的辩论：ORM鼓励人们不屑于“直接” DB交互，这通常以牺牲标准化/参照完整性为代价。将表强制映射到任意对象层次结构，但要以隐含在关系模型中的设计为代价。OOP偏爱的去耦在这里可以说是牺牲了，因为应用程序使它在数据结构中感觉到了设计。尽管ORM已显示出巨大的实用性，但它似乎是基于对SQL的滥用或不信任。

（重新）出现了新的范例，例如功能编程。如果开发团队决定采用一种新的编程方法，那么这对于根据ORM的要求构造的数据有什么影响？

我同意@Jacek Prucia的观点-我认为ORM对于RDBMS来说是一个糟糕的选择，我个人选择在RDBMS上使用DBAL，或者选择使用ORM的OODB。

约束是您在数据库级别具有一致性和数据完整性的唯一保证。当然，您可以使用应用程序代码强制执行约束，但是如果将来需要直接修改数据怎么办？您可能了解如何维护数据完整性，但其他人则可能不了解。将约束保持在数据级别可确保即使有人在他们不了解的地方闲逛时也能确保完整性。

此外，假设您的应用程序需要重写，但要使用相同的数据库。代码中的所有这些限制只是在乞求一些错误，这些错误会阻止某些条目进入，同时允许错误数据通过。

开发时，请保持简单。约束使您可以做到这一点。（也就是说，当约束引发错误时，请不要向用户吐出相同的错误。使错误易于理解。）

（关于级联问题：这是一件好事。我宁愿抛出一个错误，指出必须先删除某些其他记录，而不是依靠级联才能使所有事情都正确。级联理论上很好，但不一定所以在实践中。）

数据库中的约束的一个问题是，它们为程序提供了有关失败原因和解决方法的有限信息。这意味着，为了进行平滑处理，通常需要在应用程序中重复进行约束检查，因此浪费了数据库约束检查。

这冒着损害数据完整性的风险，因此我们在这里进行了权衡。对于重要数据，确保数据完整性几乎总是比性能更重要，即使事务看起来是任意的，也要使事务失败比弄乱数据要好得多。

为了安全地删除约束，因此确保数据库访问的安全至关重要，因此如果不检查约束就无法更改数据库。当编写新的应用程序或提出临时的数据处理方式时，这是不可靠的，因为这仅是一个错误，并且数据库已损坏。

因此，为了免除数据库约束，必须预先确定数据库可以做什么和不能做什么，以便可以广泛地编写，检查和测试所有应用程序。必须预先建立所有数据库要求，对数据库要求的任何更改都将需要大量的工作。这是一种冻结瀑布方法，仅在非常特殊的情况下有效。（根据需求进行设计，实施和维护就像在水上行走一样。必须先冻结某些东西，如果冻结得不够充分，则结果可能是灾难性的。）

确实起作用的一个例子是大型企业应用程序，例如PeopleSoft和SAP，其中该应用程序实际上已经执行了所有操作，并且有精心定义的扩展方法。还有其他非常罕见的可能性。

因此，除非您从事大型企业项目（而且我不想这么做）或可以走水，否则将这些约束留在数据库中。