“将业务逻辑移动到应用层”可以提高性能吗?

In my current project, the business logic is implemented in stored procedures (a 1000+ of them) and now they want to scale it up as the business is growing. Architects have decided to move the business logic to application layer (.net) to boost performance and scalability. But they are not redesigning/rewriting anything. In short the same SQL queries which are fired from an SP will be fired from a .net function using ADO.Net. How can this yield any performance?

To the best of my understanding, we need to move business logic to application layer when we need DB independence or there is some business logic that can be better implemented in a OOP language than an RDBMS engine (like traversing a hierarchy or some image processing, etc..). In rest of the cases, if there is no complicated business logic to implement, I believe that it is better to keep the business logic in DB itself, at least the network delays between application layer and DB can be avoided this way.

Please let me know your views. I am a developer looking at some architecture decisions with a little hesitation, pardon my ignorance in the subject.

#0

Architectural arguments such as these often need to consider many trades-off, considering performance in isolation, or ideed considering only one aspect of performance such as response time tends to miss the larger picture.

There clearly some trade off between executing logic in the database layer and shipping the data back to the applciation layer and processing it there. Data-ship costs versus processing costs. As you indicate the cost and complexity of the business logic will be a significant factor, the size of the data to be shipped would be another.

It is conceivable, if the DB layer is getting busy, that offloading processing to another layer may allow greater overall throughput even if the individual responses time are increased. We could then scale the App tier in order to deal with some extra load. Would you now say that performance has been improved (greater overall throughput) or worsened (soem increase in response time).

Now consider whether the app tier might implement interesting caching strategies. Perhaps we get a very large performance win - no load on the DB at all for some requests!

#1

If your business logic is still in SQL statements, the database will be doing as much work as before, and you will not get better performance. (may be more work if it is not able to cache query plans as effectivily as when stored procedures were used)

To get better performance you need to move some work to the application layer, can you for example cache data on the application server, and do a lookup or a validation check without hitting the database?

#2

I think those decisions should not be justified using architectural dogma. Data would make a great deal more sense.

Statements like "All business logic belongs in stored procedures" or "Everything should be on the middle tier" tend to be made by people whose knowledge is restricted to databases or objects, respectively. Better to combine both when you judge, and do it on the basis of measurements.

For example, if one of your procedures is crunching a lot of data and returning a handful of results, there's an argument that says it should remain on the database. There's little sense in bringing millions of rows into memory on the middle tier, crunching them, and then updating the database with another round trip.

Another consideration is whether or not the database is shared between apps. If so, the logic should stay in the database so all can use it.

Middle tiers tend to come and go, but data remains forever.

I'm an object guy myself, but I would tread lightly.

It's a complicated problem. I don't think that black and white statements will work in every case.

#3

Well as others have already said, it depends on many factors. But from you question it seems the architects are proposing moving the stored procedures from inside DB to dynamic SQL inside the application. That sounds very dubious to me. SQL is a set oriented language and business logic that requires massaging of large amount of data records would be better in SQL. Think complicated search and reporting type function. On the other hand line item edits with corresponding business rule validation is much better being done in a programming language. Caching of slow changing data in app tier is another advantage. This is even better if you have dedicated middle tier service that acts as a gateway to all the data. If data is shared directly among disparate applications then stored proc may be a good idea. You also have to factor the availability/experience of SQL talent vs programming talent in the organisation. There is realy no general answer to this question.

推荐文章

游戏缓存粗谈

游戏缓存粗谈

推荐文章

redis在java-itoo的实现思路

redis在java-itoo的实现思路

推荐文章

day 15 内置函数二 递归 lamda sorted filter map 二分法求值

day 15 内置函数二 递归 lamda sorted filter map 二分法求值

推荐文章

/proc文件系统简介

/proc文件系统简介

推荐文章

#1# path模块

#1# path模块

推荐文章

关于 多进程epoll 与 “惊群”问题

关于 多进程epoll 与 “惊群”问题

推荐文章

适配器(Adapter)初认识

适配器(Adapter)初认识

推荐文章

Activity中使用PagerAdapter实现切换代码

Activity中使用PagerAdapter实现切换代码

推荐文章

Ubuntu_1204_64bit 通过工具 squid cache 搭建代理服务器

Ubuntu_1204_64bit 通过工具 squid cache 搭建代理服务器

推荐文章

Linux平台下的HA软件介绍

Linux平台下的HA软件介绍

推荐文章

改造mondrian的构想

改造mondrian的构想

推荐文章

C++继承详解

C++继承详解

推荐文章

Android图片缓存库使用经验总结

Android图片缓存库使用经验总结

推荐文章

工作流参与者和工作项模式分析

工作流参与者和工作项模式分析

推荐文章

Android-Universal-Image-Loader 图片异步加载类库的使用(超详细配置)

Android-Universal-Image-Loader 图片异步加载类库的使用(超详细配置)

推荐文章

windows安装redis

windows安装redis