数据验证应该在数据库级别完成吗？

Question

我正在编写一些存储过程来创建表并添加数据。其中一个字段是指示百分比的列。那里的值应该是0-100。我开始思考，“应该在哪里进行数据验证？一般情况下应该在哪里进行数据验证？是否是个案情况？”

我觉得虽然今天我已经确定0-100是百分比的有效值，明天，我可能会认为任何正值都是有效的。所以这可能是一个商业规则，不是吗？是否应在数据库级别实施业务规则？

只是寻找指导，我们再也没有dba了。

Answer 1

一般来说，我会在多个地方进行验证：

1. 客户端使用aspx页面上的验证器
2. 背后的代码中的服务器端验证

我使用数据库验证作为最后的手段，因为数据库跳闸通常比上面讨论的两个验证更昂贵。

我绝对不是说“不要在数据库中放置验证”，但我想说，不要让它成为你验证的唯一地方。

如果您的数据被多个应用程序使用，那么最合适的位置将是（应该）由多个应用程序使用的中间层。

当您根据业务规则开始考虑整个应用程序时，您在业务规则方面提出的要求会有一个完全不同的维度。如果验证问题足够小，可以在单独的地方进行，而不是构建集中的业务规则系统。如果它是一个相当大的系统，那么您可以查看业务规则引擎。

Answer 2

一般来说，我认为验证越接近数据越好。

这样，如果您需要重写顶级应用程序或者您有第二个应用程序正在进行数据访问，那么您没有两个（可能不同的）代码副本在相同数据上运行。

Answer 3

如果您拥有良好的数据访问层，那么采用哪种方法几乎无关紧要。

也就是说，数据库约束比应用程序层约束更难以绕过（有意或无意）。

在我的工作中，我尽可能地将业务逻辑和约束保持在尽可能接近数据库的位置，确保潜在的故障点更少。根据约束的性质，在不同的层强制执行不同的约束，但数据库中可以的所有内容，在数据库中。

Answer 4

这将取决于您如何与数据库IMO进行交互。例如，如果数据库的唯一途径是通过您的应用程序，那么只需在那里进行验证。

如果您要允许其他应用程序更新数据库，那么您可能希望将验证放在数据库中，这样无论数据如何进入，它都会在最低级别进行验证。

但是，验证应该在各个层面进行，以便为用户提供最快的机会，让他们知道存在问题。

您没有提到哪个版本的SQL Server，但您可以查看用户定义的数据类型，看看是否可以帮助您，因为您可以集中验证。

Answer 5

我曾在一家政府机构工作过，而且我们有一套商业规则。我是DBA之一，我们在数据库中实现了大量的业务规则;但是，我们必须保持它们非常简单，以避免甲骨文可怕的“变异表”错误。如果您想使用触发器来实现跨越多个表的业务规则，事情会变得非常复杂。

我们的决定是尽可能在数据库中实施业务规则，因为数据是通过应用程序进入的 - 并且 - 通过数据迁移脚本。当需要将数据迁移到新数据库时，仅在应用程序中保留业务规则不会有太大作用。

我建议大多数情况下在应用程序中实现业务规则，除非您在应用程序之外的其他地方修改了数据。通过这种方式维护和修改业务规则可能更容易。

Answer 6

可以提出一个案例：

• 在数据库实施中足以确保整体数据的完整性（例如在SO中，这可能是每个问题/答案至少有一个修订版）。

• 在表示层和业务逻辑层之间的界限中，确保数据对业务逻辑有意义（例如，在SO中确保标记不包含危险标记）

但是，对于每种情况，可以轻松地为应用程序层中的不同位置创建案例。数据库存在的总体原理可能会影响这一点（例如，作为整体的应用程序的数据库部分，或者它是许多客户端的共享数据存储库）。

我唯一要避免的是在数据库中使用触发器，虽然它们可以解决遗留问题（如果你不能改变客户端......），它们就是Action at a Distance反模式的情况。

Answer 7

我认为您描述的基本数据验证可确保输入的数据正确无误。应用程序应该验证数据，但是在数据库上再次验证数据并没有什么坏处。特别是如果有多种方法可以访问数据库。

Answer 8

在完美的世界中，与数据库交谈（更新，删除，插入）的唯一方法就是您的业务API。在完美的世界中，数据库级别约束是浪费时间，您的数据已经过验证并在您的业务API中进行交叉检查。 在现实世界中，我们让牛仔采取捷径，其他人直接写入数据库。在这种情况下，对数据库的一些限制值得付出努力。但是，如果你有人不使用你的api进行读/写，你必须考虑你在api设计中出错的地方。

Answer 9

您可以合理地限制数据库，以便数据始终有意义。数据库将支持使用相同数据的多个应用程序，因此一些限制是有意义的。

我认为这样做的唯一实际成本就是时间。我认为除非你做一些疯狂的事情，否则这些限制并不是什么大问题。并且，如果需要，您可以稍后更改规则（尽管某些更改显然比其他更难）

Answer 10

第一个理想：拥有一个“看门人”，以便您的数据的一致性不依赖于每个开发人员应用相同的规则。可以在DB中合理地实现诸如范围验证的简单验证。如果它改变了至少你有什么地方可以放。

麻烦的是“业务规则”往往变得更加复杂。将处理卸载到应用程序层可能很有用，其中OO语言可以更好地管理复杂的逻辑。

然后诀窍是构建应用程序层，以便网守清晰且不重复。

在一个小型组织中（没有DBA，小吗？）我倾向于将业务规则放在具有强大开发专业知识的地方。

这并不排除在更高级别进行初始验证，例如，您可能会在UI中一直验证以帮助用户正确完成，但您不能依赖验证 - 你仍然有看门人。

Answer 11

如果百分比总是'部分除以整数'（并且您不将部分和整个值保存在其他地方），则在数据库级别检查其值[0-100]是否合适。其他限制应适用于其他级别。

如果您的百分比意味着某种增长，那么它可能具有任何类型的值，不应在数据库级别进行检查。

是个案情况。通常你应该只检查数据库级别的约束，这些约束永远不会改变或具有自然限制（如第一个例子）。

Answer 12

理查德是对的：问题是主观的问题。

另一个观点是：对此有什么想法？它们是否因行业或技术而异？

我现在一直在做Ruby on Rails，在那里，甚至记录之间的关系（一对多等）在数据库级别上都没有得到尊重，更不用说级联删除和所有这些东西了。除了允许DB完成其工作的基本数据类型之外，它们都没有任何限制。您的百​​分比不是在数据库级别处理，而是在数据模型级别处理。

所以我认为我们最近看到的一个趋势是为应用级别提供更多功能。您必须检查进入您服务器的数据（所以在演示级别的某个地方）并且您可以在客户端上检查它，然后您可以再次检查应用程序的业务层。为什么要在数据库级别再次检查它？

但是：最糟糕的事情确实发生了，有时数据库会获得“不可能”读取业务层代码的值。因此，如果您正在管理财务数据，我会说在每个级别都可能存在每个限制。不同部门的人做什么？