Arguments for/against Business Logic in stored procedures [closed]

Answer 1

Some thoughts: Please note this is a Java centric response, but its the bulk of my recent (last 10years) experience

(1) Concurrent development by a (a large) team of developers. If you're application is sufficiently complex that each developer can't set up their own private version of the DB (with attended links/ref data/etc...)it is very difficult to have an entire TEAM of developers all working on the same set of PL-SQL (for example) packages at the same time stored in a shared DEVL DB? Then your stuck (my experience) with working in a DB with invalid procedures / mismatch of code to tables as people make changes...

As a Java architect, I think its much easier to have each developer have a private JBoss instance on their desktop and work easily on their own set of functionality, and integrating at their own pace without impacting everyone else ... which brings me to ...

(2) Continuous Integration toolsets While there exist some similar 'concepts' in the DB world, my experience has shown me that the combo of (i'm picking my current best-of-breed favs here):

• mvn - build system
• junit - automated unit testing
• nexus - repo manager (manages artifact's lifecycles version, snapshots and releases)
• hudson - ci build server
• sonar - static analysis tool / code coverage reports / ALOT more

Running a large project using all of the above (free tools) allows a consistent / easy way to deliver XP to the masses and enforce quality controls over a whole IT staff. Oracle / PL-SQL doesn't have the toolsets to match

(3) tools / libraries / etc... Java has access to an amazing set of services that other platforms cannot touch - some free, some not. even basic ones, like log4j (yes they have it for PL/SQL, but pulease...its not nearly the same) allows for things like allowing developers to create flexibly adjustable logging that can be changed on the fly (perfect for dubugging). Automated API documentation (via javadoc). Automated unit test coverage reports. Incredible IDEs (Eclipse) with integrated debuggers / autodeploy to app servers. An API to interface with every type of service under the sun, open source libraries to do ANYTHING, and 100% support by every vendor

(4) reuse of services. what someone commented on is true. If you have heavy duty data driven business rules then you can argue that these should live in the DB layer. Why? to prevent having the middle tier(s) all having to duplicate that logic.

But the same can be said for business rules that are not data driven or sufficiently complex that OO is a more natural choice. If you stick ALL business logic in the DB, then they're available only via the DB.

• What if you want to have validation done in the client or middle app tier and save a round trip to the DB?
• What if you want to cache read only data in the middle tier (for performance) and have business rules execute against the cached data?
• What if you have a middle tier service that doesn't require DB access, or you have a client that can supply their own data?
• What if the data dependent portion of the business rules then needs to access external services? Then you end with with fragmented business logic that looks like this:

i

retCode = validateSomeDate(date);
if (retCode == 1) then
   evaluateIfCustomerGetsEmail(...)//probably more stored proc invocations here...
   sendEmailMsg(....)
else if (retCode == 2) then
   performOtherBizLogicStuf(...) //again, may need data, may not need data
   triggerExternalsystemToDoSomething(...) //may not be accessible via PL/SQL 
fi

I'm sure we've all seen systems written like the one above and had to debug them at 2AM. Its extremely difficult to get a coherent sense of a complex process when the business logic is fragmented between tiers, and in some cases it gets to be impossible to maintain.

Answer 2

I'm of the school of thought that says that as long as business logic:

• lives in one place
• where it is properly documented
• proper access is provided through services that can be loosely coupled
• through a published abstracted interface

I don't care if the logic lives in a stored procedure, in a J2EE middle tier, in a clips expert system, or wherever. No matter where you store our business logic the "law of conservation of misery" is going to guarantee that someone will say it was the wrong idea because component/repository X needs to be swapped out for technology/method Y.

Answer 3

I am thoroughly against it. One of the biggest reasons is the first reason earino stated - it lives in one place. You can not integrate it into source control very easily. It is next to impossible to have two devs working on a stored proc at the same time.

My other main complaint is that SQL is just not very good at representing complex logic. You have no concept of scope, code tends to be copy-pasted because there is a less ability to reuse code (as opposed to an OO language).

You have to give developers access to the database to develop there. In many organizations I have worked at the data people are in a different world than the devs, with different permissions, etc. Keeping the devs out of the database in these cases would be harder.

Answer 4

+: SQL server sometimes optimizes the code

+: You are forced to pass parameters, which limits SQL injection issues

-: Your code depends on a single database (some dbs don't even have SP)

-: To change code you need to connect to database

-: Logic is not organized well

Personally I'm against it, but I had to use it once on a really busy website. Using SP in MS SQL brought huge benefits, but once I implemented caching those benefits were not so big anymore.

Answer 5

My rule of thumb (once I recognized what it was by thinking about the question) is that stored procedures should contain code that ensures data integrity within the database, whether the stored procedure prohibits certain data insertion, deletion or modification, or makes other changes necessary for data consistency. Business logic, especially logic that cannot be implemented in a handful of set-based operations, should be implemented elsewhere. Databases are not applications. Databases should be the ultimate authority for relationships and constraints, even if the business rules are also implemented elsewhere for, say, the provision of feedback in user interface code that reduces postbacks from a web server or eliminates otherwise unnecessary hits on a busy server. One can argue whether "data consistency" includes the result of complex processing of complex business rules, but I think it's usually clear once the context is understood. Not all business rules are implemented as data relationships or constraints. Not all operations in a stored procedure are faster than code running in a separate process, even on a process running on a separate machine across a network. I recently did a demonstration showing that many operations in SSIS, for example, (INSERT INTO () SELECT FROM) perform faster in SSIS running across a network on a separate machine than running in a stored procedure (that also inserts the results to a database across the network). This is an almost unbelievable result (where SSIS is faster than raw SQL statements), and demonstrates that the discovery of the best optimization of any performance issues comes from reality (testing) and not from logic based on only a few concepts. (We still have to make decisions on what to test by rules of thumb learned by experience.) (SSIS performed faster by automatically implementing multithreading and pipelines, using BULK INSERT even where it wasn't specified in the raw SQL statement, and sending batches of inserts on one thread while creating additional BULK INSERTs on other threads. In this instance, it performed about twice as fast as raw SQL statements.) When I used to teach programming and SQL Server courses, PowerBuilder users seemed to have the statement "Native drivers provide the fastest data access" burned into their tongue, and while it might be justified through additional (unrecognized by them) explanation, the thinking behind it is misleading.

Answer 6

There is a saying...

When all you have is a hammer, everything looks like a nail.

In my humble opinion there is no one answer that will fit all circumstances. It seems to me that many people just assume that putting Business Logic in the database is always wrong.

A lot of work has been done to make transaction processing, especially bulk operations, very efficient when done on the database side. Also the code management in databases has vastly improved since most of the opinions against databases were formed.

I think it is wrong to consider the database server as just a persistence layer. If your processing activities are most efficient when done on the DB Server then do them there.

If not then do them elsewhere.

It all comes down to what best fits the application you are working on at the moment, the team with whom you are working and the customer who hired you.

That just my 2 cents.