假设应用程序在模型/表示层中具有所有必要的业务规则,并且它们可以正常工作。我的问题是,是否应在SQL Server等存储库中使用冗余业务规则(即两个日期的跨度不能与任何其他现有跨度重叠)。
在SQL Server中添加强制执行此规则的约束是否必要/有益?一方面,它可以防止任何人(包括DBA)在绕过应用程序时无意中破坏业务规则。此外,我们已经通过主键和外键在存储库中拥有某些形式的业务规则。另一方面,重复的规则需要额外的时间来开发和维护。
这个问题涵盖了许多不同的技术,所以我故意保持标签的通用性。
答案 0 :(得分:6)
如果您关心自己的数据,则会将所需规则放在其他任何地方。数据受到应用之外的许多地方的影响。仅在业务层中放置规则是短暂的,并导致严重的数据完整性问题atat可能是非常可怕的尝试修复。有关数据的规则属于数据库。
答案 1 :(得分:5)
您通常会发现很难在多个地方手动维护业务规则。
我已经在一些项目中充分利用代码生成来从需求模型生成某些类型的规则。例如,我可能要求“名字不得超过50个字符”。我以结构化的方式在UML中对该需求进行建模,然后生成UI代码以将输入限制为50个字符,业务逻辑强制执行相同的限制(从不信任UI!),并使用DDL / ORM映射文件指定列宽DB。
同样的想法可以扩展到更复杂的规则建模,并在应用程序的每一层生成适当的执行代码。
答案 2 :(得分:5)
业务规则或数据完整性规则?
我的经验(大多数是大公司,我们不是在谈论软件公司或业余爱好商店)是你的数据库将比应用程序更耐用。并最终有其他应用程序与它交谈。如果没有任何规则(无论何种类型),有人会在某个地方破坏数据库。
答案 3 :(得分:1)
你自己说过......什么强制执行后门的业务规则(即DBA戳戳数据)。如果你担心会发生这种情况,那么付出代价。如果没有,那么请将其关闭,以便其他地方强制执行的规则不会多余。
答案 4 :(得分:0)
取决于您的应用程序 - 如果要与数据库无关,请将逻辑保留在应用程序代码中。否则,业务规则更适合数据库。