我试图找出我是否应该在数据库内部的触发器或约束中使用业务关键逻辑.
到目前为止,我已经在触发器中添加了逻辑,因为它让我可以控制接下来发生的事情,这意味着我可以提供自定义用户消息而不是可能会混淆用户的错误.
使用约束优先于触发器是否有任何明显的性能提升,以及确定使用哪些优先实践的最佳实践.
制约约束!
有了约束,您可以指定关系原则,即有关数据的事实.除非某些事实发生变化(即新要求),否则您永远不需要更改约束.
使用触发器指定如何处理数据(插入,更新等).这是一种"非关系"的做事方式.
通过类比来更好地解释自己:编写SQL查询的正确方法是指定"你想要的"而不是"如何获得它" - 让RDBMS找出最适合你的方法.这同样适用于此:如果你使用触发器,你必须记住各种事情,如执行顺序,级联等等......如果可能的话,让SQL为你做限制.
这并不是说触发器没有用途.他们这样做:有时您不能使用约束来指定有关数据的某些事实.这是非常罕见的.如果碰巧你很多,那么有可能是一些问题与架构.
最佳实践:如果您可以使用约束来执行此操作,请使用约束.
触发器并没有那么糟糕(如果使用得当),尽管我总是会尽可能地使用约束.在现代RDMS中,触发器的性能开销与约束相当(当然,这并不意味着某人不能在触发器中放置可怕的代码!).
偶尔有必要使用触发器来强制执行"复杂"约束,例如想要强制执行一个并且只填充一个表的两个外键字段中的一个(我在少数域模型中看到过这种情况).
关于业务逻辑应该驻留在应用程序而不是数据库中的争论在某种程度上取决于环境; 如果您有许多应用程序访问数据库,则约束和触发器都可以作为数据正确的最终保护.
触发器可能会成为一个性能问题.大约在同一时间,它们也成为维护的噩梦.您无法弄清楚正在发生的事情和(奖励!)应用程序与"虚假"数据问题的行为不规律.[真的,它们会触发问题.]
没有最终用户直接接触SQL.他们使用应用程序.应用程序包含的业务逻辑比触发器更智能,更易于维护.将应用程序逻辑放在应用程序中.将数据放入数据库.
除非您和您的"用户"不共享共同语言,否则您可以向他们解释违规行为.替代方案 - 不解释 - 将一个简单的数据库变成一个问题,因为它将数据和应用程序代码混合成一个不可维护的泥潭.
"我如何绝对保证每个人都正确使用数据模型？"
两种(半)技术.
确保模型是正确的:它匹配现实世界的问题域.没有黑客或变通方法或快捷方式,只能通过复杂的挥手解释,存储过程和触发器进行整理.
帮助定义应用程序的业务模型层.每个人共享和重用的应用程序代码层.
一个.此外,请确保模型层满足人们的需求.如果模型层具有正确的方法和集合,那么绕过它以获得对底层数据的直接访问的动机就会减少.一般来说,如果模型是正确的,这不是一个深刻的问题.
触发器是一种等待发生的火车残骸.限制不是.
除了使用约束的其他原因之外,Oracle优化器还可以使用约束来获得优势.
例如,如果您有一个约束说(Amount >= 0),然后您使用WHERE (Amount = -5)Oracle 查询立即知道没有匹配的行.
约束和触发器适用于两种不同的事物.约束用于约束数据的域(有效输入).例如,SSN将存储为char(9),但约束为[0-9] [0-9] [0-9] [0-9] [0-9] [0-9] [ 0-9] [0-9] [0-9](全数字).
触发器是一种在数据库中实施业务逻辑的方法.再次考虑SSN,每当SSN发生变化时,可能需要维护审计跟踪 - 这将通过触发器来完成,
通常,可以使用约束的某些变体来处理现代RDBMS中的数据完整性问题.但是,您有时会遇到这样的情况:不正确的规范化(或更改的要求,导致现在不正确的规范化)会阻止约束.在这种情况下,触发器可能能够强制执行您的约束 - 但它对RDBMS是不透明的,这意味着它不能用于优化.它也是"隐藏"的逻辑,可能是一个维护问题.决定是否重构模式或使用触发器是此时的判断调用.
京公网安备 11010802040832号 | 京ICP备19059560号-6 