数据库层的业务逻辑
我不想再次问“数据库中的业务逻辑与代码中的业务逻辑”这个经典问题，但我需要一些具体的理由来说服老的开发团队，代码中的业务逻辑更好，因为它更易于维护。我曾经在数据库中有很多业务逻辑，因为我相信它是单点访问。如果我是唯一一个进行更换的人，维护就很容易了。根据我的经验，当项目变得更大、更复杂时，问题就会出现。 DB 存储过程的源代码控制并不像较新的 IDE 那样先进，编辑器也不是。我在最近的经验中发现，代码中的业务逻辑比数据库中的业务逻辑可以更好地扩展。
因此，在 stackoverflow 上搜索时，我发现其受人尊敬的成员提出了完全相反的理念：
https://stackoverflow。 com/search?q=business+logic+in+database
我知道任何情况都没有绝对的，但是对于给定的 ASP.NET 解决方案，它将使用 sql server 或 oracle，对于一个不是特别的情况高流量网站，为什么我要把逻辑在数据库中？
I hate to ask the classic question of "business logic in database vs code" again, but I need some concrete reasons to convince an older team of developers that business logic in code is better, because it's more maintainable, above all else. I used to have a lot of business logic in the DB, because I believed it was the single point of access. Maintenance is easy, if I was the only one doing the changing it. In my experience, the problems came when the projects got larger and complicated. Source Control for DB Stored Procs are not so advanced as the ones for newer IDEs, nor are the editors. Business logic in code can scale much better than in the DB, is what I've found in my recent experience.
So, just searching around stackoverflow, I found quite the opposite philosophy from its esteemed members:
https://stackoverflow.com/search?q=business+logic+in+database
I know there is no absolute for any situation, but for a given asp.net solution, which will use either sql server or oracle, for a not a particularly high traffic site, why would I put the logic in the DB?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
取决于你所谓的商业。
数据库应该执行预期的操作。
如果数据的消费者和提供者希望数据库做出一定的保证，那么就需要在数据库中完成。
有些人不在数据库中使用引用完整性，并期望系统的其他部分来管理它。有些人直接访问数据库中的表。
我觉得从系统和组件的角度来看，数据库就像任何其他服务或类/对象一样。它需要保护其边界，隐藏其实现细节并提供完整性保证，从低级完整性到一定级别，这可能被视为“业务”。
做到这一点的好方法是引用完整性、存储过程、触发器（必要时）、视图、隐藏基表等。
Depends on what you call business.
The database should do what is expected.
If the consumers and providers of data expect the database to make certain guarantees, then it needs to be done in the database.
Some people don't use referential integrity in their databases and expect the other parts of the system to manage that. Some people access tables in the database directly.
I feel that from a systems and component perspective, the database is like any other service or class/object. It needs to protect its perimeter, hide its implementation details and provide guarantees of integrity, from low-level integrity up to a certain level, which may be considered "business".
Good ways to do this are referential integrity, stored procedures, triggers (where necessary), views, hiding base tables, etc., etc.
数据库负责数据工作，为什么要压低已经受到严重打击的东西来为您提供数据呢？这是性能问题和代码问题。维护业务逻辑代码比将其全部存储在数据库中要容易得多。存储过程、视图和函数只能走这么远，直到您拥有带有存储过程的视图的视图的视图来填补这一混乱。通过业务逻辑，您可以分离您的担忧。如果您有一个错误导致某些计算错误，那么检查业务逻辑代码比进入数据库并查看是否有人弄乱了存储过程中的某些内容更容易。这是非常固执己见的，在某些情况下，将一些逻辑放入数据库中是可以的，但我对此的想法是，它是一个数据库而不是逻辑库，把东西放在它们所属的地方。
PS：这篇文章可能会引起一些热议，它非常固执己见，除了性能数据之外，没有任何真正的证据，这成为你正在处理的事情的一个例子。
编辑：凯德提到的一些事情我忘记了。引用完整性。无论如何，请在数据库中保持正确的数据完整性，删除级联时没有孤立记录、检查等。
Database does data things, why weigh down something that is already getting hit pretty hard to give you data. It's a performance thing and a code thing. It's MUCH easier to maintain business logic code than to store it all in the database. Sprocs, Views and Functions can only go so far until you have Views of Views of Views with sprocs to fill that mess in. With business logic you separate your worries. If you have a bug that's causing something to be calculated wrong it's easier to check the business logic code than go into the DB and see if someone messed up something in a Stored Procedure. This is highly opinionated and in some cases it's OK to put some logic in the database but my thoughts on this are it's a database not a logicbase, put things where they belong.
P.S: Might be catchin some heat for this post, it's highly opinionated and other than performance numbers there's no real evidence for either and it becomes a case of what you're working with.
EDIT: Something that Cade mentioned that I forgot. Refrential integrity. By all means please have correct data integrity in your DB, no orphaned records ON DELETE CASCADE's, checks and whatnot.
我在一个大型项目中遇到过数据库逻辑。这是由作为DBA专家的主要管理者的决定造成的。他说应用程序应该是轻量级的，它应该对数据库方案、连接表等一无所知，而且无论如何存储过程的执行速度比事务范围和来自客户端的查询快得多。
另一方面，我们在数据库对象映射方面存在太多错误（基于其他视图的视图等存储的产品或视图）。我们无法了解我们的数据发生了什么，因为单击的每个按钮都称为一个包含 70-90-120 个参数的巨大存储过程，并更新了多个 (10-15) 个表。我们无法查询简单的选择请求，因此我们必须在代码中编译一个视图或存储的 Proc 和类，这只是为了一个简单的连接:-(当然，当表或视图定义更改时，您应该重新编译所有其他基于 DB 对象的在其他地方编辑的对象上，您将得到运行时异常。
所以我认为数据库中的逻辑是一种可怕的方式。当然，如果出于性能或安全问题的需要，您可以将一些代码存储在存储过程中，但您不应该在数据库中开发所有内容）逻辑应该灵活，可测试和可维护，并且使用数据库无法达到这一点存储逻辑）
I have faced with database logic on one of huge projects. This was caused by the decision of main manager who was the DBA specialist. He said that the application should be leightweight, it should know nothing about database scheme, joined tables, etc, and anyway stored Procs executes much faster than the transaction scopes and queries from client.
At the other side, we had too much bugs with database object mappings (stored prod or view based on view based on other view etc). It was unreachable to understand what is happening with our data because of each button clicked called a huge stored proc with 70-90-120 parameters and updated several (10-15) tables. We had no ability to query simple select request so we had to compile a view or stored Proc and class in code for this just for one simple join :-( of course when the table or view definition changes you should recompile all other dB objects based on edited object elsewhere you will get runtime Exception.
So I think that logic in database is a horrible way. Of course you can store some pieces of code in stored procs if needed by performance or security issues, but you shoul not develop everything in the Database) the logic should be flexible, testable and maintenable, and you can not reach this points using database for storing logic)