标签 database
<分区>
我最近注意到一种趋势，即人们正在将越来越多的处理从数据库转移到应用程序中。有些人将此推向了我认为荒谬的极端。
我见过应用程序设计不仅禁止所有存储过程的使用，而且还禁止在数据库中强制执行任何类型的约束(这包括主键、外键、唯一和检查约束)。我什至见过只需要使用一种存储在数据库中的数据类型的应用程序，即 varchar(2000)。不允许使用 DateTime 和数字类型。事务和并发也在数据库外处理。
有没有人见过这类应用程序成功实现？我处理过的两个以这种方式实现的实现都存在各种数据完整性和并发性问题。谁能解释这种将内容(逻辑、处理、约束)移出数据库的趋势？其背后的动机是什么？这是我的想象吗？
最佳答案
首先，我真的希望没有 PK 和 FK 以及合理的数据类型的数据库没有趋势。那真是一场悲剧。
但是肯定有很大一部分开发人员更喜欢将逻辑放在他们的应用程序中而不是存储过程中。我同意 Riho 对此的主要原因:通常，DBA 管理数据库，这意味着开发人员必须经历一系列管理开销——获得 DBA 的批准——才能创建和更新存储过程。程序员天生喜欢控制他们的世界，并按“他们的方式”做事。
还有几个有效的技术原因:
我个人的看法是，核心业务逻辑越接近数据越好，尤其是当不止一个代理访问数据库(或者将来可能会)的时候。 T-SQL 及其同类语言是弱语言，这是一个不幸的历史产物，这导致了“数据和逻辑应该分离”的想法的兴起。在我的理想世界中，每条业务规则都封装在数据库强制执行的约束中，所有不一致的地方都会快速失败。
关于database - 多少应用程序 "smarts"应该驻留在数据库中？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/464272/