目前我们正在使用检查约束来实现业务规则，但我想知道是否应该在SQL或业务逻辑层（C＃）中实现业务规则。我在网上搜索过，发现检查约束很好用。
如果有人知道有关它的详细信息，请告诉我。还有一件事是，可以使用移动应用程序以及使用Web应用程序将数据泵入我的数据库。
答案 0 :(得分：5)
是的，这很好！
您应该始终在应用代码中（在业务层中）检查业务规则，但是如果可能的话也在数据库中检查。
为什么呢？想象一下有人设法在不使用您的应用程序的情况下向您的数据库提交一些数据 - 如果您在应用程序中只有 ，则不会应用这些检查。
如果您对数据库进行了检查，则可以确保数据库中的数据至少符合可以在SQL CHECK CONSTRAINTS中制定的那些简单检查。
绝对使用那些！您需要尝试尽可能高地保持数据质量 - 在数据库上添加参照完整性，检查约束和唯一约束等等可以帮助您实现这一目标。
不单独依靠您的应用程序！
答案 1 :(得分：5)
是的，检查约束是业务规则的有效工具。
但是您确定需要使用检查约束，还是使用具有外键关系的支持表？如果您发现自己在不同的地方定义了类似的检查约束 - 答案是肯定的，这绝对应该是一个支持表。
数据完整性是关键;如果应用程序被规避，那么允许某人存储不符合业务规则的内容的系统没有多大价值。如果逻辑在数据库中，原始应用程序在C＃中，并且高层决定市场需要Java / Ruby / Python / etc版本，它也会使生活变得更容易。
答案 2 :(得分：2)
你应该尽可能使用CHECK约束，但我也不会过度使用它。如果在不使用应用程序的情况下无法将数据导入数据库，则可以安全地使用最小的CHECK约束和繁重的业务验证。
在SQL中定义严格的业务规则可能相当困难。坚持数据库中的数据验证，以及应用程序中的实际业务规则。
此外，尝试以一种使用外键等输入错误数据的方式来安排架构。
答案 3 :(得分：1)
随着您的数据库越来越“智能”，它所包含的数据的完整性将更加安全。所以，是的，我认为实施它是好的和重要的。
这带来了许多好处：如果有多个应用程序修改数据（例如：C＃app + Web应用程序+移动应用程序......），您可以确保您的数据是安全的，并且它允许您制作在那些“secundary”应用程序中减少工作量。如果数据库完成所有工作，则应用程序只是数据库的前端。
将来迁移应用程序会更容易，但迁移数据库会更加困难。这是一个重要的决定。
答案 4 :(得分：1)
取决于约束
可以并且应该在数据库中应用一些约束，例如外键约束和唯一性。数据库将能够快速有效地应用这些数据。
其他更复杂的“业务”约束更好地应用于业务逻辑层。这些示例可能是“客户在允许购买之前必须拥有经过验证的电子邮件地址”。在数据库中应用这些将是复杂和繁重的 - 您冒着在SQL中编写系统的风险，这是一个坏主意。
答案 5 :(得分：1)
C＃。在C＃中重用逻辑比在SQL中（根据我的经验）更容易并且通常维护。