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

Answer 1

DBMS != Application server

• Functional programming (DB Stored procedure) vs OOP. For big programs is OOP just standard.
• IDE - eclipse, intellij, netbeans with all plugins for debugging, testing and analysis works only with real programming languages. Static code tools.
• Version control if you get one for PLSQL & co. is great. If you get "synchronize view" direct from you IDE - you are real the lucky one.
• Scale your system. For DB system is hell. You need expensive hardware for other "nodes". Replication. And probably licence for every node. Don't forget you are still in "functional programming" and effort to understand and maintain such systems is much bigger.
• You are stuck with your DB, try to change or add a new one from another company
• And so on...

Stored procedure for business logic is bad practise today. Use 3-Tier architecture instead.

Answer 2

One more reason NOT to store business logic in sprocs - limited scaling abilities of the DB. It is very common situation where your database is your bottleneck, that is why it is a good idea to take as much load of the DB as possible.

Answer 3

Business logic should be encapsulated in one place. We can guarantee that the logic is always run and run consistently. Using classes that all activity involving an entity on the database must run through we can guarantee that all validation is run properly. There is one place for this code and any developer on the project can easily open this class and see the logic (because documentation can and does get out of date, the code is the only reliable form of documentation).

This is difficult to do with stored procedures. You may have more than one sproc dealing with the same table(s). Chaining multiple sprocs together so that the logic resides in only one gets unwieldy. That is strike one. How do you determine "What are all of the business rules surrounding entity X" within the database? Have fun searching thousands of sprocs trying to track that down.

Number two is that you are tying your business logic to your persistence mechanism. You may not store all of your data in the same database, or some may reside in XML etc. This type of inconsistency is difficult on the developer.

Validation is difficult to perform if the logic resides only in the database. Do you really call a sproc to validate every field on your data entry form? Validation rules and business logic are close cousins. This logic should all be performed in the same place!

Answer 4

"You can not integrate it into source control very easily." - if you put the code that creates the stored proc into a script that's version controlled, that objection goes away. If you follow Scott Ambler's agile database ideas, that's exactly what you should be doing.

Not all developers are good data modelers. I can think of horrible schemas created by developers who thought that a dabbling knowledge of SQL made them database experts. I think there's a lot of value to having developers working with DBAs and data modelers.

If only one application uses the database, I'd say that business logic can appear in the middle tier. If many apps share the database, perhaps it's better to put it in the database.

SOA offers a middle way: services own their data. Only the service has access to the data; getting to data means going through the service. In that case, it's possible to put the rules in either place.

Applications come and go, but data remains.

Answer 5

There are different kinds of "business logic". Consider partitioning it based on how it's related to other layers or services. Here are some rules of thumb from an MVC perspective:

a) In the database (stored procedure) if it's mostly data-related, and can be done with joins and relatively simple WHERE and SELECT clauses.

b) In the controller if it's mostly routing or dispatching related; that is, larger-scale UI flow control in terms of screen or resource selection.

c) In the model or view-model if it involves complex or intricate computations and/or conditionals.

d) In the view (such as Razor) if it's primarily a display issue, such as "friendly" re-formatting and relatively simple to implement. (If it's complex, consider putting it in a view-model.)

Answer 6

With all this micro-services and micro business components ideology we are way ahead of questioning the right place to put our business logic.

Even though the ideology is well accepted we still have temptation and some instances where we ended up putting some decision making and business logic in database. It’s worth visiting detailed answer to why it should not be done, but at macro level I would advise thinking about one good reason why it should stay in stored-procedure and not in the application layer.

Having that counter thought process would always direct taking the right decision. Ask these questions before deciding:

1. What if down the line we change our database from SQL to Mongo?
2. What if want to expose API which takes the data (that database is providing) and apply this business logic on top?
3. Unit testing this business logic?
4. SDLC steps involved if we make change in conditions of this business logic?
5. What if we need another user input for the decision making in this business logic?
6. What if it requires high computation power (not data processing) and we want to be run off a separate process (or platform) ?

In all cases it would make natural choice to not put any logic (other than just data retrieval) in business logic.