对商业规则使用检查约束是否好使用

Question

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

如果有人知道更详细的信息，请让我知道。还有一件事是可以使用移动应用程序将数据输入到我的数据库中，并使用Web应用程序。

Answer 1

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

但你确定你需要使用检查约束，或使用支持表与外键关系？如果你发现自己在不同的地方定义了类似的检查限制 - 答案是肯定的，这肯定是一个支持表。

数据完整性是关键;如果系统允许一个人存储不符合商业规则的东西，那么这个系统没有太大的价值。如果逻辑位于数据库中，那么当原始应用程序使用C＃并且高层决定市场需要Java/Ruby/Python /等版本时，它也使生活变得更容易。

Answer 2

是的，它是好的！

你真的应该经常检查您的业务规则都在（在业务层）您的应用程序代码，但如果有的话也可能在你的数据库。

为什么？想象一下，有人设法向您的数据库提交一些数据而不使用您的应用程序 - 如果您在应用程序中只有支票，则这些支票不会被应用。

如果你有数据库的检查，以及，你可以确保在数据库中的数据是否符合至少那些简单的检查，可以在SQL CHECK约束来制定。

绝对使用这些！您需要尝试尽可能保持数据质量 - 在数据库中添加参照完整性，检查约束条件和唯一约束条件等等可以帮助您做到这一点。

做不单靠你的应用程序！

Answer 3

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

这具有许多优点：如果有多个应用程序修改数据（例如：C＃app + Web应用程序+移动应用程序...），您可以确保您的数据安全，并且它允许您在那些“secundary”应用程序中减少工作量。如果数据库完成所有工作，则应用程序只是数据库的前端。

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

Answer 4

你应该尽可能使用CHECK约束，但我也不会这样做。如果没有可能在没有使用应用程序的情况下将数据存入数据库，那么使用最少的CHECK约束和繁重的业务验证就可以保证安全。

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

另外，尝试以这样的方式，使得它很难与外国键等，输入错误的数据来安排你的架构。

Answer 5

取决于约束

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

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

其他更复杂的“业务”约束更适用于业务逻辑层。这些例子可能是“在允许购买之前，客户必须有经过验证的电子邮件地址”。在数据库中应用这些将会很复杂和繁琐 - 你会冒SQL编码系统的风险，这是一个糟糕的想法。

Answer 6

C＃。在C＃中重新使用逻辑要比SQL更容易（根据我的经验）并且通常会保持。