应用程序"智能"应该驻留在数据库中多少？

我最近注意到一种趋势,人们正在越来越多地处理数据库和应用程序.有些人认为这对我来说是荒谬的极端.

我已经看到应用程序设计不仅禁止使用存储过程,而且还禁止在数据库中强制执行任何类型的约束(这将包括主键,外键,唯一和检查约束).我甚至看到过只需要使用数据库中存储的一种数据类型的应用程序,即varchar(2000).不允许使用DateTime和数字类型.事务和并发也在数据库外部处理.

有没有人见过这类应用程序成功实现？我所处理的两个实现都是以这种方式实现的,具有各种数据完整性和并发性问题.任何人都可以解释这种趋势,将数据(逻辑,处理,约束)移出数据库吗？它背后的动机是什么？这是我想象的东西吗？

首先,我真的希望没有PKs和FK以及合理数据类型的数据库没有趋势.这真的是一个悲剧.

但肯定有大量的开发人员喜欢在他们的应用程序中使用逻辑而不是存储过程.我同意Riho的主要原因是:通常,DBA管理数据库,这意味着开发人员必须经历一系列管理开销 - 获得DBA的批准 - 以便创建和更新存储过程.程序员本质上喜欢控制他们的世界,并以"他们的方式"做事.

还有一些有效的技术原因:

用于开发存储过程的SQL(例如T-SQL)的过程扩展传统上缺乏用户定义的数据类型,可调试性,可移植性以及与外部系统的互操作性 - 所有质量都有助于开发可靠的大型软件.(而且笨拙的语法无济于事.)

软件版本控制(例如svn)适用于管理甚至非常大的代码库,但管理数据库模式更改是一个更难的问题,并且支持不太好.每个认真的商店都对其应用程序代码库使用版本控制,但许多仍然没有任何严格的系统来管理他们的数据库; 因此,存储过程很容易陷入一个无法解决的"黑洞",使编码员正确紧张.

我个人认为,核心业务逻辑越接近数据越好,特别是如果有多个代理访问数据库(或将来可能会这样做).这是一个令人遗憾的历史人工制品,T-SQL及其类似弱语言,导致"数据和逻辑应该分离"这一观念的兴起.我的理想世界是每个业务规则都封装在数据库强制执行的约束中,并且所有不一致性都会快速失败.

我喜欢把逻辑排除在数据库之外.我倾向于避免存储过程和触发器.但是,我总是使用正确的数据类型,键,标记和约束.我看到它的方式是数据库是一个数据库,应用程序是应用程序.数据库应该保持您的数据正确有效地存储,而应用程序应该拥有逻辑.也许我从来没有遇到需要存储过程或触发器的情况; 因此从未倾向于用它们来解决问题.但对我来说,给逻辑提供数据库的主页对我来说似乎"混乱"; 我宁愿控制应用程序本身的所有内容.