业务逻辑：数据库或应用程序层
老问题了。 您应该将业务逻辑放在哪里，作为存储过程（或包）放在数据库中，还是放在应用程序/中间层中？ 更重要的是，为什么？
假设数据库独立性不是目标。
The age old question. Where should you put your business logic, in the database as stored procedures ( or packages ), or in the application/middle tier? And more importantly, Why?
Assume database independence is not a goal.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（24）
在确定业务逻辑应该放在哪里时，代码的可维护性始终是一个大问题。
集成的调试工具和更强大的 IDE 通常使维护中间层代码比存储过程中的相同代码更容易。 除非有真正的原因，否则您应该从中间层/应用程序中的业务逻辑开始，而不是从存储过程中开始。
然而，当您进行报告和数据挖掘/搜索时，存储过程通常是更好的选择。 这要归功于数据库聚合/过滤功能的强大功能，以及您保持处理非常接近数据源的事实。 但这可能不是大多数人认为的经典业务逻辑。
Maintainability of your code is always a big concern when determining where business logic should go.
Integrated debugging tools and more powerful IDEs generally make maintaining middle tier code easier than the same code in a stored procedure. Unless there is a real reason otherwise, you should start with business logic in your middle tier/application and not in stored procedures.
However when you come to reporting and data mining/searching, stored procedures can often a better choice. This is thanks to the power of the databases aggregation/filtering capabilities and the fact you are keeping processing very close the the source of the data. But this may not be what most consider classic business logic anyway.
将足够的业务逻辑放入数据库中，以确保数据的一致性和正确性。
但不要担心必须在另一个级别复制一些逻辑来增强用户体验。
Put enough of the business logic in the database to ensure that the data is consistent and correct.
But don't fear having to duplicate some of this logic at another level to enhance the user experience.
对于非常简单的情况，您可以将业务逻辑放入存储过程中。 通常，即使是简单的情况也会随着时间的推移而变得复杂。 以下是我不将业务逻辑放入数据库的原因：
将业务逻辑放入数据库将其与数据库的技术实现紧密耦合。 更改表将导致您再次更改许多存储过程，从而导致许多额外的错误和额外的测试。
通常，UI 取决于验证等业务逻辑。 将这些内容放入数据库将导致数据库和 UI 之间的紧密耦合，或者在不同情况下会重复这两者之间的验证逻辑。
让多个应用程序在同一个数据库上工作将变得很困难。 对一个应用程序的更改将导致其他应用程序崩溃。 这很快就会变成维护噩梦。 所以它并没有真正扩展。
更实际的是，SQL 并不是一种以可理解的方式实现业务逻辑的好语言。 SQL 非常适合基于集合的操作，但它缺少“大规模编程”的构造，因此很难维护大量存储过程。 现代面向对象语言更适合并且更灵活。
这并不意味着您不能使用存储过程和视图。 我认为有时在表和应用程序之间放置额外的存储过程和视图层以将两者解耦是个好主意。 这样您就可以更改数据库的布局，而无需更改外部接口，从而允许您独立重构数据库。
For very simple cases you can put your business logic in stored procedures. Usually even the simple cases tend to get complicated over time. Here are the reasons I don't put business logic in the database:
Putting the business logic in the database tightly couples it to the technical implementation of the database. Changing a table will cause you to change a lot of the stored procedures again causing a lot of extra bugs and extra testing.
Usually the UI depends on business logic for things like validation. Putting these things in the database will cause tight coupling between the database and the UI or in different cases duplicates the validation logic between those two.
It will get hard to have multiple applications work on the same database. Changes for one aplication will cause others to break. This can quickly turn into a maintenance nightmare. So it doesn't really scale.
More practically SQL isn't a good language to implement business logic in an understandable way. SQL is great for set based operations but it misses constructs for "programming in the large" it's hard to maintain big amounts of stored procedures. Modern OO languages are better suited and more flexible for this.
This doesn't mean you can't use stored procs and views. I think it sometimes is a good idea to put an extra layer of stored procedures and views between the tables and application(s) to decouple the two. That way you can change the layout of the database without changing external interface allowing you to refactor the database independently.
这完全取决于您，只要您始终如一。
将其放入数据库层的一个很好的理由是：如果您相当确定您的客户永远不会更改其数据库后端。
将其放在应用程序层的一个很好的理由是：如果您的应用程序针对多种持久性技术。
您还应该考虑核心能力。 你们的开发人员主要是应用层开发人员，还是主要是DBA类型的？
It's really up to you, as long as you're consistent.
One good reason to put it in your database layer: if you are fairly sure that your clients will never ever change their database back-end.
One good reason to put it in the application layer: if you are targeting multiple persistence technologies for your application.
You should also take into account core competencies. Are your developers mainly application layer developers, or are they primarily DBA-types?
虽然没有一个正确的答案 - 这取决于所讨论的项目，但我建议使用“领域驱动设计n”作者：Eric Evans。 在这种方法中，业务逻辑被隔离在它自己的层中 - 域层 - 位于基础设施层之上 - 可能包括您的数据库代码，并且位于应用程序层下方，它将请求发送到域层实现并监听其完成的确认，从而有效地推动应用程序。
这样，业务逻辑就被捕获在一个模型中，除了技术问题之外，还可以与那些了解业务的人进行讨论，并且它应该可以更容易地隔离业务规则本身的变化、技术实现问题以及业务流程。与业务（域）模型交互的应用程序。
如果有机会的话，我建议您阅读上面的书，因为它很好地解释了如何在真实代码和项目的现实世界中实际近似这种纯粹的理想。
While there is no one right answer - it depends on the project in question, I would recommend the approach advocated in "Domain Driven Design" by Eric Evans. In this approach the business logic is isolated in its own layer - the domain layer - which sits on top of the infrastructure layer(s) - which could include your database code, and below the application layer, which sends the requests into the domain layer for fulfilment and listens for confirmation of their completion, effectively driving the application.
This way, the business logic is captured in a model which can be discussed with those who understand the business aside from technical issues, and it should make it easier to isolate changes in the business rules themselves, the technical implementation issues, and the flow of the application which interacts with the business (domain) model.
I recommend reading the above book if you get the chance as it is quite good at explaining how this pure ideal can actually be approximated in the real world of real code and projects.
虽然将业务逻辑放在应用程序层肯定有好处，但我想指出的是，语言/框架的变化似乎比数据库更频繁。
我支持的一些系统在过去 10-15 年经历了以下 UI：Oracle Forms/Visual Basic/Perl CGI/ASP/Java Servlet。 没有改变的一件事是关系数据库和存储过程。
While there are certainly benefits to have the business logic on the application layer, I'd like to point out that the languages/frameworks seem to change more frequently then the databases.
Some of the systems that I support, went through the following UIs in the last 10-15 years: Oracle Forms/Visual Basic/Perl CGI/ ASP/Java Servlet. The one thing that didn't change - the relational database and stored procedures.
数据库独立性（提问者在本例中排除作为考虑因素）是将逻辑从数据库中剔除的最有力的论据。 数据库独立性最有力的论据是能够向自己偏好数据库后端的公司销售软件。
因此，我认为从数据库中取出存储过程的主要论点只是商业方面的，而不是技术方面的。 可能有技术原因，但也有将其保留在那里的技术原因——例如性能、完整性以及允许多个应用程序使用相同 API 的能力。
是否使用 SP 也很大程度上受到您要使用的数据库的影响。 如果您不考虑数据库独立性，那么使用 T-SQL 或使用 PL/SQL 时您将获得截然不同的体验。
如果您使用 Oracle 开发应用程序，那么 PL/SQL 作为语言是显而易见的选择。 它与数据紧密耦合，在每个版本中不断改进，任何像样的开发工具都会将 PL/SQL 开发与 CVS 或 Subversion 等集成。
Oracle 基于 Web 的 Application Express 开发环境甚至 100% 使用 PL/SQL 构建。
Database independence, which the questioner rules out as a consideration in this case, is the strongest argument for taking logic out of the database. The strongest argument for database independence is for the ability to sell software to companies with their own preference for a database backend.
Therefore, I'd consider the major argument for taking stored procedures out of the database to be a commercial one only, not a technical one. There may be technical reasons but there are also technical reasons for keeping it in there -- performance, integrity, and the ability to allow multiple applications to use the same API for example.
Whether or not to use SP's is also strongly influenced by the database that you are going to use. If you take database independence out of consideration then you're going to have very different experiences using T-SQL or using PL/SQL.
If you are using Oracle to develop an application then PL/SQL is an obvious choice as a language. It's is very tightly coupled with the data, continually improved in every relase, and any decent development tool is going to integratePL/SQL development with CVS or Subversion or somesuch.
Oracle's web-based Application Express development environment is even built 100% with PL/SQL.
数据库中唯一存在的就是数据。
存储过程是维护的噩梦。 它们不是数据，也不属于数据库。 开发人员和 DBA 之间无休止的协调只不过是组织摩擦。
对存储过程保持良好的版本控制是很困难的。 数据库外部的代码确实很容易安装——当您认为自己的版本错误时，您只需执行 SVN UP（也许是安装），您的应用程序就会恢复到已知状态。 您拥有环境变量、目录链接以及对应用程序的大量环境控制。
您可以通过简单的
PATH操作，获得适用于不同情况（培训、测试、QA、生产、客户特定增强功能等）的变体软件。但是，数据库内的代码，更难管理。 没有适当的环境——没有“路径”、目录链接或其他环境变量——来提供对正在使用的软件的任何可用的控制； 您在数据库中拥有一组永久的、全球范围内绑定的应用程序软件，与数据结合在一起。
触发因素甚至更糟。 它们都是维护和调试的噩梦。 我不知道他们解决了什么问题； 它们似乎是解决设计糟糕的应用程序的一种方法，在这些应用程序中，有人懒得正确使用可用的类（或函数库）。
虽然有些人认为性能论点很有说服力，但我仍然没有看到足够的基准数据来说服我存储过程是如此之快。 每个人都有自己的轶事，但没有人拥有算法或多或少相同的并行代码。
[在我看到的例子中，旧的应用程序设计得很糟糕，一团糟； 当存储过程被编写时，应用程序被重新架构。 我认为设计变更比平台变更的影响更大。]
The only thing that goes in a database is data.
Stored procedures are a maintenance nightmare. They aren't data and they don't belong in the database. The endless coordination between developers and DBA's is little more than organizational friction.
It's hard to keep good version control over stored procedures. The code outside the database is really easy to install -- when you think you've got the wrong version you just do an SVN UP (maybe an install) and your application's back to a known state. You have environment variables, directory links, and lots of environment control over the application.
You can, with simple
PATHmanipulations, have variant software available for different situations (training, test, QA, production, customer-specific enhancements, etc., etc.)The code inside the database, however, is much harder to manage. There's no proper environment -- no "PATH", directory links or other environment variables -- to provide any usable control over what software's being used; you have a permanent, globally bound set of application software stuck in the database, married to the data.
Triggers are even worse. They're both a maintenance and a debugging nightmare. I don't see what problem they solve; they seem to be a way of working around badly-designed applications where someone couldn't be bothered to use the available classes (or function libraries) correctly.
While some folks find the performance argument compelling, I still haven't seen enough benchmark data to convince me that stored procedures are all that fast. Everyone has an anecdote, but no one has side-by-side code where the algorithms are more-or-less the same.
[In the examples I've seen, the old application was a poorly designed mess; when the stored procedures were written, the application was re-architected. I think the design change had more impact than the platform change.]
任何影响数据完整性的内容都必须放在数据库级别。 除了用户界面之外的其他东西经常将数据放入数据库、更新或删除数据库中的数据，包括导入、批量更新以更改定价方案、修补程序等。如果您需要确保始终遵循规则，请将逻辑设置为默认值和触发器。
这并不是说在用户界面中也包含它不是一个好主意（为什么要费心发送数据库不接受的信息），而是在数据库中忽略这些内容会招致灾难。
Anything that affects data integrity must be put at the database level. Other things besides the user interface often put data into, update or delete data from the database including imports, mass updates to change a pricing scheme, hot fixes, etc. If you need to ensure the rules are always followed, put the logic in defaults and triggers.
This is not to say that it isn't a good idea to also have it in the user interface (why bother sending information that the database won't accept), but to ignore these things in the database is to court disaster.
如果您需要数据库独立性，您可能希望将所有业务逻辑放在应用程序层中，因为应用程序层中可用的标准比数据库层中可用的标准普遍得多。
但是，如果数据库独立性不是第一因素，并且您的团队的技能包括强大的数据库技能，那么将业务逻辑放入数据库可能被证明是最好的解决方案。 您可以让应用程序人员执行特定于应用程序的操作，并让数据库人员确保所有查询顺利进行。
当然，能够将 SQL 语句组合在一起和拥有“强大的数据库技能”之间存在很大的区别 - 如果您的团队更接近前者而不是后者，那么使用这个世界上的 Hibernate 之一将逻辑放入应用程序中（或者改变你的团队！）。
根据我的经验，在企业环境中，您将拥有该领域的单一目标数据库和技能 - 在这种情况下，将所有内容都放入数据库中。 如果您从事软件销售业务，数据库许可成本将使数据库独立性成为最大的因素，并且您将在应用程序层中实施您可以实施的一切。
希望有帮助。
If you need database independence, you'll probably want to put all your business logic in the application layer since the standards available in the application tier are far more prevalent than those available to the database tier.
However, if database independence isn't the #1 factor and the skill-set of your team includes strong database skills, then putting the business logic in the database may prove to be the best solution. You can have your application folks doing application-specific things and your database folks making sure all the queries fly.
Of course, there's a big difference between being able to throw a SQL statement together and having "strong database skills" - if your team is closer to the former than the latter then put the logic in the application using one of the Hibernates of this world (or change your team!).
In my experience, in an Enterprise environment you'll have a single target database and skills in this area - in this case put everything you can in the database. If you're in the business of selling software, the database license costs will make database independence the biggest factor and you'll be implementing everything you can in the application tier.
Hope that helps.
将代码放在应用程序层将产生一个独立于数据库的应用程序。
有时，出于性能原因，使用存储过程更好。
它（像往常一样）取决于应用程序的要求。
Putting the code in the application layer will result in a DB independent application.
Sometimes it is better to use stored procedures for performance reasons.
It (as usual) depends on the application requirements.
现在可以提交颠覆您的存储过程代码并在良好的工具支持下调试该代码。
如果使用组合 sql 语句的存储过程，则可以减少应用程序和数据库之间的数据流量，并减少数据库调用的次数，并获得巨大的性能提升。
一旦我们开始使用 C# 进行构建，我们就决定不使用存储过程，但现在我们正在将越来越多的代码移至存储过程。 特别是批处理。
但是不要使用触发器，使用存储过程或更好的包。 触发器确实会降低可维护性。
It is nowadays possible to submit to subversion your stored proc code and to debug this code with good tool support.
If you use stored procs that combine sql statements you can reduce the amount of data traffic between the application and the database and reduce the number of database calls and gain big performance gains.
Once we started building in C# we made the decision not to use stored procs but now we are moving more and more code to stored procs. Especially batch processing.
However don't use triggers, use stored procs or better packages. Triggers do decrease maintainability.
业务逻辑应该优先放置在应用程序/中间层。 这样，它可以以域模型的形式表示、放置在源代码管理中、与相关代码拆分或组合（重构）等。它还为您提供了一定的数据库供应商独立性。
面向对象语言也比存储过程更具表现力，使您可以更好、更轻松地在代码中描述应该发生的情况。
将代码放置在存储过程中的唯一充分理由是：如果这样做会产生显着且必要的性能优势，或者如果相同的业务代码需要由多个平台（Java、C#、PHP）执行。 即使使用多个平台，也有其他替代方案，例如可能更适合共享功能的网络服务。
The business logic should be placed in the application/middle tier as a first choice. That way it can be expressed in the form of a domain model, be placed in source control, be split or combined with related code (refactored), etc. It also gives you some database vendor independence.
Object Oriented languages are also much more expressive than stored procedures, allowing you to better and more easily describe in code what should be happening.
The only good reasons to place code in stored procedures are: if doing so produces a significant and necessary performance benefit or if the same business code needs to be executed by multiple platforms (Java, C#, PHP). Even when using multiple platforms, there are alternatives such as web-services that might be better suited to sharing functionality.
根据我的经验，答案存在于一系列价值观中的某个位置，这些价值观通常由组织的技能所在决定。
DBMS是一个非常强大的野兽，这意味着正确或不正确的处理将带来巨大的好处或巨大的危险。 遗憾的是，在太多的组织中，主要关注的是编程人员； 数据库管理系统技能，尤其是查询开发技能（而不是管理技能）被忽视了。 由于评估 dbms 技能的能力也可能缺失，这一事实加剧了这种情况。
很少有程序员能够充分理解他们不了解的数据库知识。
因此，次优概念的流行，例如 Active Records 和 LINQ（引入一些明显的偏见）。 但它们可能是此类组织的最佳答案。
但请注意，规模较大的组织往往更加关注数据存储的有效使用。
The answer in my experience lies somewhere on a spectrum of values usually determined by where your organization's skills lie.
The DBMS is a very powerful beast, which means proper or improper treatment will bring great benefit or great danger. Sadly, in too many organizations, primary attention is paid to programming staff; dbms skills, especially query development skills (as opposed to administrative) are neglected. Which is exacerbated by the fact that the ability to evaluate dbms skills is also probably missing.
And there are few programmers who sufficiently understand what they don't understand about databases.
Hence the popularity of suboptimal concepts, such as Active Records and LINQ (to throw in some obvious bias). But they are probably the best answer for such organizations.
However, note that highly scaled organizations tend to pay a lot more attention to effective use of the datastore.
这个问题没有独立的正确答案。 这取决于您的应用程序的要求、开发人员的偏好和技能以及月相。
There is no standalone right answer to this question. It depends on the requirements of your app, the preferences and skills of your developers, and the phase of the moon.
业务逻辑应放在应用程序层而不是数据库中。
原因是数据库存储过程始终取决于您使用的数据库产品。 这打破了三层模型的优点之一。 除非您为此数据库产品提供额外的存储过程，否则您无法轻松更改为其他数据库。
另一方面，有时，将逻辑放入存储过程中以优化性能是有意义的。
我想说的是业务逻辑是要放到应用层的，但是也有例外（主要是性能原因）
Business logic is to be put in the application tier and not in the database.
The reason is that a database stored procedure is always dependen on the database product you use. This break one of the advantages of the three tier model. You cannot easily change to an other database unless you provide an extra stored procedure for this database product.
on the other hand sometimes, it makes sense to put logic into a stored procedure for performance optimization.
What I want to say is business logic is to be put into the application tier, but there are exceptions (mainly performance reasons)
业务应用程序“层”包括：
1. 用户界面
这实现了业务用户对工作的视图。 它使用用户熟悉的术语。
2. 处理
这是计算和数据操作发生的地方。 任何涉及更改数据的业务逻辑都在这里实现。
3. 数据库
这可以是： 标准化顺序数据库（标准的基于 SQL 的 DBMS）； 面向对象数据库，存储包装业务数据的对象； 等等。
走向何处
在到达上述各层时，您需要进行必要的分析和设计。 这将表明业务逻辑最好在哪里实现：数据完整性规则和有关数据更新的并发/实时问题通常会尽可能靠近数据实现，与计算字段相同，这是一个很好的指针存储过程/触发器，其中数据完整性和事务控制是绝对必要的。
涉及数据含义和使用的业务规则大部分将在处理层中实现，但也会作为用户的工作流出现在用户界面中 - 以反映数据的某种顺序链接各个流程。用户的工作。
Bussiness application 'layers' are:
1. User Interface
This implements the business-user's view of h(is/er) job. It uses terms that the user is familiar with.
2. Processing
This is where calculations and data manipulation happen. Any business logic that involves changing data are implemented here.
3. Database
This could be: a normalized sequential database (the standard SQL-based DBMS's); an OO-database, storing objects wrapping the business-data; etc.
What goes Where
In getting to the above layers you need to do the necessary analysis and design. This would indicate where business logic would best be implemented: data-integrity rules and concurrency/real-time issues regarding data-updates would normally be implemented as close to the data as possible, same as would calculated fields, and this is a good pointer to stored-procedures/triggers, where data-integrity and transaction-control is absolutely necessary.
The business-rules involving the meaning and use of the data would for the most part be implemented in the Processing layer, but would also appear in the User-Interface as the user's work-flow - linking the various process in some sequence that reflects the user's job.
恕我直言。 在决定业务逻辑在关系数据库驱动的应用程序中的位置时，存在两个相互冲突的问题：
和可靠性。 可维护性：为了实现高效的未来开发，业务逻辑属于应用程序中最容易调试和版本控制的部分。
关于。 可靠性：当存在重大不一致风险时，业务逻辑属于数据库层。 关系数据库可以设计为检查数据的约束，例如不允许特定列中出现 NULL 值等。 当应用程序设计中出现某些数据需要处于过于复杂的特定状态的情况时表达了这些简单的约束，在数据库层使用触发器或类似的东西是有意义的。
触发器很难保持最新状态，尤其是当您的应用程序应该在客户端系统上运行时，您甚至无权访问。 但这并不意味着无法跟踪或更新它们。 S.Lott 在他的回答中认为这是一种痛苦和麻烦的论点是完全正确的，我会支持这一点，并且也曾经经历过。 但是，如果您在首次设计数据层时牢记这些限制，并且除了绝对必要的情况之外不要使用触发器和函数，这是可以管理的。
在我们的应用程序中，大多数业务逻辑都包含在应用程序的模型层中，例如发票知道如何根据给定的销售订单初始化自身。 当针对这样一组复杂的更改连续修改一堆不同的内容时，我们将它们汇总在事务中以保持一致性，而不是选择存储过程。 总数的计算等都是通过模型层的方法完成的。 但是，当我们需要对某些内容进行非规范化以提高性能或将数据插入所有客户端使用的“更改”表中以找出它们需要在会话缓存中过期的对象时，我们使用数据库层中的触发器/函数来插入新行并从此触发器发出通知（Postgres 监听/通知内容）。
我们的应用程序在该领域投入使用大约一年，每天都有数百名客户使用，如果我们从头开始，我唯一要改变的就是设计我们的系统来创建数据库函数（或存储过程，无论您如何选择）从一开始就考虑到版本控制和更新。
值得庆幸的是，我们确实有一些系统来跟踪架构版本，因此我们在此基础上构建了一些系统来负责替换数据库功能。 如果我们从一开始就考虑到更换它们的必要性，现在会节省我们一些时间。
当然，当您走出 RDBMS 领域并进入 Amazon SimpleDB 和 Google BigTable 等元组存储系统时，一切都会发生变化。 但那是一个不同的故事:)
Imho. there are two conflicting concerns with deciding where business logic goes in a relational database-driven app:
Re. maintainability: To allow for efficient future development, business logic belongs in the part of your application that's easiest to debug and version control.
Re. reliability: When there's significant risk of inconsistency, business logic belongs in the database layer. Relational databases can be designed to check for constraints on data, e.g. not allowing NULL values in specific columns, etc. When a scenario arises in your application design where some data needs to be in a specific state which is too complex to express with these simple constraints, it can make sense to use a trigger or something similar in the database layer.
Triggers are a pain to keep up to date, especially when your app is supposed to run on client systems you don't even have access too. But that doesn't mean it's impossible to keep track of them or update them. S.Lott's arguments in his answer that it's a pain and a hassle are completely valid, I'll second that and have been there too. But if you keep those limitations in mind when you first design your data layer and refrain from using triggers and functions for anything but the absolute necessities it's manageable.
In our application, most business logic is contained in the application's model layer, e.g. an invoice knows how to initialize itself from a given sales order. When a bunch of different things are modified sequentially for a complex set of changes like this, we roll them up in a transaction to maintain consistency, instead of opting for a stored procedure. Calculation of totals etc. are all done with methods in the model layer. But when we need to denormalize something for performance or insert data into a 'changes' table used by all clients to figure out which objects they need to expire in their session cache, we use triggers/functions in the database layer to insert a new row and send out a notification (Postgres listen/notify stuff) from this trigger.
After having our app in the field for about a year, used by hundreds of customers every day, the only thing I would change if we were to start from scratch would be to design our system for creating database functions (or stored procedures, however you want to call them) with versioning and updates to them in mind from the get-go.
Thankfully, we do have some system in place to keep track of schema versions, so we built something on top of that to take care of replacing database functions. It would've saved us some time now if we'd considered the need to replace them from the beginning though.
Of course, everything changes when you step outside of the realm of RDBMS's into tuple-storage systems like Amazon SimpleDB and Google's BigTable. But that's a different story :)
对于将业务逻辑放在中间层或应用程序层而不是数据库层来说，可扩展性也是非常重要的因素。应该理解，DatabaseLayer 仅用于与数据库交互，而不是操作从数据库返回或从数据库返回的数据。
Scalability is also very important factor for pusing business logic in middle or app layer than to database layer.It should be understood that DatabaseLayer is only for interacting with Database not manipulating which is returned to or from database.
这是一个连续体。 恕我直言，最大的因素是速度。 你怎样才能让这个傻瓜尽快启动并运行，同时仍然遵守良好的编程原则，例如可维护性、性能、可伸缩性、安全性、可靠性等。很多时候，SQL 是表达某些东西的最简洁的方式，而且也恰好是很多时候性能最高，除了字符串操作等，但这就是 CLR 过程可以提供帮助的地方。 我的信念是，在您认为最适合手头工作的任何地方自由地运用业务逻辑。 如果你有一群在查看 SQL 时尿裤子的应用程序开发人员，那么就让他们使用他们的应用程序逻辑吧。 如果您确实想创建具有大型数据集的高性能应用程序，请在数据库中放入尽可能多的逻辑。 解雇您的 DBA，并为开发人员提供对其开发数据库的最终自由。 对于这项工作，没有一个答案或最好的工具。 您拥有多种工具，因此成为应用程序各个级别的专家，您很快就会发现您花费了更多的时间在有保证的情况下编写简洁的表达性 SQL，而在其他时候则使用应用程序层。 对我来说，归根结底，减少代码行数才是简化的原因。 我们刚刚将一个只有 2500 行应用程序代码和 1000 行 SQL 的 sql 丰富应用程序转换为一个域模型，该模型现在拥有 15500 行应用程序代码和 2500 行 SQL 来实现以前的 sql 丰富应用程序所做的事情。 如果您可以将代码增加 6 倍证明为“简化”，那么就继续吧。
It's a continuum. IMHO the biggest factor is speed. How can u get this sucker up and running as quickly as possible while still adhering to good tenants of programming such as maintainability, performance, scalability, security, reliability etc. Often times SQL is the most concise way to express something and also happens to be the most performant many times, except for string operations etc, but that's where your CLR Procs can help. My belief is to liberally sprinkle business logic around whereever you feel it is best for the undertaking at hand. If you have a bunch of application developers who shit their pants when looking at SQL then let them use their app logic. If you really want to create a high performance application with large datasets, put as much logic in the DB as you can. Fire your DBA's and give developers ultimate freedom over their Dev databases. There is no one answer or best tool for the job. You have multiple tools so become expert at all levels of the application and you'll soon find that you're spending a lot more time writing nice consise expressive SQL where warranted and using the application layer other times. To me, ultimately, reducing the number of lines of code is what leads to simplicity. We have just converted a sql rich application with a mere 2500 lines of app code and 1000 lines of SQL to a domain model which now has 15500 lines of app code and 2500 lines of SQL to achieve what the former sql rich app did. If you can justify a 6 fold increase in code as "simplified" then go right ahead.
这是一个很好的问题！ 我在问了一个类似的问题后发现了这一点-bu">问题，但这更具体。 它是由于我没有参与制定的设计变更决定而出现的。
基本上，我被告知如果数据库表中有数百万行数据，那么请考虑将业务逻辑放入存储过程和触发器中。 这就是我们现在正在做的事情，将 java 应用程序转换为存储过程以提高可维护性，因为 java 代码变得很复杂。
我在以下位置找到了这篇文章：业务逻辑战争作者还在表参数中设置了百万行，我觉得这很有趣。 他还在 JavaScript 中添加了业务逻辑，这是客户端和业务逻辑层之外的。 尽管我多年来一直使用 javascript 进行验证以及服务器端验证，但我之前从未考虑过这一点。
我的观点是，您希望将应用程序/中间层中的业务逻辑作为经验法则，但不要忽视将其放入数据库中有意义的情况。
最后一点，我目前工作的另一个小组正在做大量的数据库研究工作，他们处理的数据量是巨大的。 尽管如此，对于他们来说，数据库本身没有任何业务逻辑，而是将其保留在应用程序/中间层中。 对于他们的设计，应用程序/中间层是正确的位置，所以我不会使用表的大小作为唯一的设计考虑因素。
This is a great question! I found this after I had already asked a simliar question, but this is more specific. It came up as a result of a design change decision that I wasn't involved in making.
Basically, what I was told was that If you have millions of rows of data in your database tables, then look at putting business logic into stored procedures and triggers. That is what we are doing right now, converting a java app into stored procedures for maintainability as the java code had become convoluted.
I found this article on: The Business Logic Wars The author also made the million rows in a table argument, which I found interesting. He also added business logic in javascript, which is client side and outside of the business logic tier. I hadn't thought about this before even though I've used javascript for validation for years, to along with server side validation.
My opinion is that you want the business logic in the application/middle tier as a rule of thumb, but don't discount cases where it makes sense to put it into the database.
One last point, there is another group where I'm working presently that is doing massive database work for research and the amount of data they are dealing with is immense. Still, for them they don't have any business logic in the database itself, but keep it in the application/middle tier. For their design, the application/middle tier was the correct place for it, so I wouldn't use the size of tables as the only design consideration.
我们将大量业务逻辑放在存储过程中 - 这并不理想，但通常它在性能和可靠性之间取得了良好的平衡。
我们知道它在哪里，而无需搜索大量的解决方案和代码库！
We put a lot of business logic in stored procedures - it's not ideal, but quite often it's a good balance between performance and reliability.
And we know where it is without having to search through acres of solutions and codebase!
我记得在某处读过一篇文章，指出在某种程度上，一切都可以是业务逻辑的一部分，因此这个问题毫无意义。
我认为给出的示例是在屏幕上显示发票。 将逾期标记为红色的决定是一项商业决策......
I remember reading an article somewhere that pointed out that pretty well everything can be, at some level, part of the business logic, and so the question is meaningless.
I think the example given was the display of an invoice onscreen. The decision to mark an overdue one in red is a business decision...
业务逻辑通常由对象以及封装、继承和多态性的各种语言结构来体现。 例如，如果银行应用程序正在传递金钱，则可能有一个 Money 类型定义“金钱”的业务元素。 这与使用原始十进制来表示货币相反。 因此，精心设计的 OOP 是“业务逻辑”所在的地方，而不是严格意义上的任何层。
Business logic is usually embodied by objects, and the various language constructs of encapsulation, inheritance, and and polymorphism. For example, if a banking application is passing around money, there may be a Money type that defines the business elements of what "money" is. This, opposed to using a primitive decimal to represent money. For this reason, well-designed OOP is where the "business logic" lives—not strictly in any layer.