sql - 对业务规则使用检查约束好不好

Question

目前我们正在使用检查约束来实现业务规则，但我想知道我们是否应该在 SQL 或业务逻辑层（C#）中实现业务规则。我在网上搜索过，发现检查约束很好用。

如果有人知道有关它的更详细信息，请告诉我。另一件事是，可以使用移动应用程序和 Web 应用程序将数据输入我的数据库。

Answer 1

是的，这很好！

您真的应该始终在您的应用程序代码（在业务层）中检查您的业务规则，但如果可能的话，也要在您的数据库中检查。

为什么？想象一下，有人设法在不使用您的应用程序的情况下将一些数据提交到您的数据库 - 如果您仅在应用程序中进行检查，则不会应用这些检查。

如果您也对数据库进行了检查，则可以确保数据库中的数据至少符合那些可以在 SQL CHECK CONSTRAINTS 中制定的简单检查。

绝对使用那些！你需要尽量保持你的数据质量尽可能高——在数据库上添加参照完整性、检查约束和唯一约束等可以帮助你做到这一点。

不要单独依赖您的应用程序！

Answer 2

是的，检查约束是业务规则的有效工具。

但是您确定需要使用检查约束，还是使用具有外键关系的支持表？如果你发现自己在不同的地方定义了类似的检查约束——答案是肯定的，这绝对应该是一个支持表。

数据完整性是关键；如果应用程序被规避，一个允许人们存储不符合业务规则的东西的系统没有多大价值。如果原始应用程序在 C# 中并且高层决定市场需要 Java/Ruby/Python/etc 版本的情况下，逻辑在数据库中，这也会使生活变得更加轻松。

Answer 3

您绝对应该尽可能使用 CHECK 约束，但我也不会过度使用它。如果不使用您的应用程序就不可能将数据输入数据库，那么您可以安全地使用最少的 CHECK 约束和繁重的业务验证。

在 SQL 中定义严格的业务规则可能相当困难。坚持数据库中的数据验证，以及应用程序中的实际业务规则。

此外，请尝试以一种难以使用外键等输入错误数据的方式来安排您的架构。

Answer 4

随着您的数据库更加“智能”，它所包含的数据的完整性将更加安全。所以，是的，我认为实施它是好的和重要的。

这带来了很多好处：如果有多个应用程序修改数据（例如：C# 应用程序 + Web 应用程序 + 移动应用程序......），您可以确保您的数据是安全的，并且它可以让您减少工作量那些“次要”应用程序。如果数据库完成所有工作，那么应用程序只是数据库的前端。

将来迁移应用程序会更容易，但迁移数据库会更加困难。这是一个重要的决定。

Answer 5

取决于约束

1. 这取决于约束
2. 您还应该尽量避免（如果可能）在 2 个地方检查相同的约束 - 这意味着您的系统中有重复的代码，从而导致不必要的复杂性。

有一些约束可以并且应该在数据库中应用，例如外键约束和唯一性。数据库将能够快速有效地应用这些。

其他更复杂的“业务”约束更好地应用于业务逻辑层。这些示例可能是“客户在允许购买之前必须拥有经过验证的电子邮件地址”。在数据库中应用这些将是复杂和繁重的——你会冒着用 SQL 对系统进行编码的风险，这是一个坏主意。

Answer 6

C＃。在 C# 中重用逻辑比 SQL 更容易（根据我的经验）并且通常可以维护。