我一直在我的应用程序层(模型)和我的数据库层(引发错误的存储过程)中实施业务规则.
由于以下几个原因,我一直在复制我在两个地方的验证：
>如果条件发生变化
当他们被检查
应用程序代码以及它们何时
在数据库中检查,
业务规则检查数据库
将节省一天.数据库
也允许我锁定各种
记录的方式比简单的方式更简单
我的应用程序代码,似乎
这是自然而然的.
>如果有的话
做一些批量数据
如果我路由,直接插入/更新数据库
通过我的所有这些操作
存储过程/函数
正在做业务规则
验证,我没有机会
即使我缺乏保护,如果我通过应用程序进行单输入,也会输入不良数据.
>虽然
只执行这些事情
数据库会产生同样的效果
关于实际数据,似乎
不正确地把数据扔到了
数据库在第一次做好之前
努力验证它是否符合
约束和业务规则.
什么是正确的平衡？
解决方法
您需要在数据层强制执行以确保数据完整性.这是你的最后一道防线,也就是数据库的工作,以帮助强制执行其数据的世界观.
也就是说,将垃圾数据抛向数据库进行验证是一种粗略的技术.通常,错误被设计为人类可读的而不是机器可读的,因此程序从DB处理错误并使其失去优势是低效的.
存储过程是另一回事.在当天,存储过程是处理数据层等业务规则的方法.
但是今天,在现代应用程序服务器环境中,它们通常成为放置这种逻辑的更好的地方.它们提供了多种访问和公开数据的方式(Web,Web服务,远程协议,API等).此外,如果您的规则是cpu重(可能大多数不是),那么扩展应用服务器比数据库服务器更容易.
应用程序服务器中的大量功能使它们具有超出数据库服务器可以执行的灵活性,因此,一旦被推回到数据库中的大部分功能都被淘汰,数据库服务器被降级为“哑持久性”.
也就是说,使用存储过程等确实存在性能优势,但现在这是一个调整问题,“问题变成”是否值得失去应用服务器功能以获得我们通过将其放入数据库服务器获得的收益“.
