数据库与代码中的业务逻辑? [英] Business Logic in Database versus Code?

问题描述

作为一名软件工程师，我非常倾向于在应用程序层编写业务逻辑，而通常只依赖数据库进行 CRUD(创建检索更新和删除)操作.另一方面，我遇到过在存储过程中编写大量业务逻辑的应用程序(通常是较旧的应用程序)，因此有些人更喜欢在数据库层编写业务逻辑.

As a software engineer, I have a strong bias towards writing business logic in the application layer, while typically relying on the database for little more than CRUD (Create Retrieve Update and Delete) operations. On the other hand, I have run across applications (typically older ones) where a large amount of the business logic was written in stored procedures, so there are people out there that prefer to write business logic in the database layer.

对于已经和/或喜欢在存储过程中编写/编写业务逻辑的人，您使用这种方法的原因是什么?

For the people that have and/or enjoy written/writing business logic in a stored procedure, what were/are your reasons for using this method?

推荐答案

我尝试将我在数据库中的业务逻辑严格限制为仅需要执行大量查询和更新才能执行单个应用程序操作的过程.有些人可能会争辩说，即使这样也应该在应用程序中，但我喜欢尽可能降低 IO.

I try to seriously limit my business logic in the DB to only procs that have to do alot of querying and updating to perform a single application operation. Some may argue that even that should be in the app, but I like to keep the IO down if I can.

数据库非常适合 CRUD，但如果它们因逻辑而变得臃肿:

Databases are great for CRUD but if they get bloated with logic:

1. 逻辑在哪里变得混乱，
2. 通常，数据库是一个孤岛，几乎不像应用服务器那样水平扩展.
3. t_sql/PLsql 本质上难以阅读和程序化
4. 您将失去 OOAD 的所有优势.

1. It becomes confusing where the logic is,
2. Typically databases are a silo and do not scale horizontally nearly as well as the app servers.
3. t_sql/PLsql is hard to read and procedural in nature
4. You forfeit all of the benefits of OOAD.

这篇关于数据库与代码中的业务逻辑?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！