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

Answer 1

@Nick "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 procedure at the same time."

Not that I'm arguing for putting business logic on stored procedures (all the contrary). But these reasons you put forward make no sense. A stored procedure is simply a sql/DDL artifact that can be stored on source control, and which is also a deployment artifact (that is, something handed over to the dba for deployment, much the same way you would hand over your war/ear artifacts to the IT/deployment liasons) One or more developers can work on the same stored procedure off source control just in the same way you'll do with plain old source code - by branching, versioning and merging.

Now, if the only copy of the stored procedure (and the packages that contain them) only exist in the database, then obviously you cannot control that with source control (and all the problems associated to that). However, that's not a problem of stored procedure but a problem of ineptitude in regard of how to use that code. It is as equally a display of ineptitude as having only one copy of your source code living on production.

I've worked in systems with massive amounts of code, both Java and PLSQL/DDLs and they were all versioned on clearcase. They were all treated as source code that would be compiled and deployed with a strict process, with different teams working on them. Never had any problem as what you are describing.

There are context-specific reasons not to put business logic in stored procedures, but these aren't valid ones.

Answer 2

My few observations:

In favour of stored procedures:

• after some time of project life, in most cases the bottleneck is the database not the web server - and stored procedures are much, much faster

• using sql profiler with ORM generated sql queries is very difficult; this is easy with stored procedures

• you can deploy a fix for stored procedure instantly, without a service window

• for performance, it is easier to optimize a stored procedure than ORM-code

• you may have many applications using the same db / stored procs

• any complex data scenario is a vote for stored procedures

In favour of application/ORM:

• you may use code repository (with stored procs it is still possible but expensive)

• java / c# language is a better tool to express business logic

• java / c# is easier to debug (except for the dynamically-generated ORM sql)

• independence of database engine (however this is not very likely that a project will change database to another one)

• ORM provides data model which is easy to use

In my opinion: for large projects - go for stored procedures, for the others - Application/ORM will work fine.

In the end of a day, the only thing which matters is the database.

Answer 3

Against stored procedures: business logic in programming space

I place a high value on the power of expression, and I don't find the SQL space to be all that expressive. Use the best tools you have on hand for the most appropriate tasks. Fiddling with logic and higher order concepts is best done at the highest level. Consequently, storage and mass data manipulation is best done at the server level, probably in stored procedures.

But it depends. If you have multiple applications interacting with one storage mechanism and you want to make sure it maintains its integrity and workflow, then you should offload all of the logic into the database server. Or, be prepared to manage concurrent development in multiple applications.

Answer 4

You can unit test business logic when its in a business logic layer. If it's completely separate the persistance operations can be mocked so you are testing the BL only. A stored proc is far more difficult to maintain/debug/unit test than e.g. linq and c#.

Answer 5

Performance will be massively improved by moving logic into the stored procs, especially if explicit transactions are involved.

In my experience, application developers aren't very good at writing optimised database code, and don't tend to think about concurrency or performance issues.
If business logic is kept in the application layer, you tend to have to shift large amounts of data (often in many round-trips) across the network, duplicate it in memory on the DB server, and at least once in the app server, and do a load of row-by-row processing in the app while you're holding open a transaction. Then the app developers complain that the database is slow and keeps deadlocking.

If you put the logic in the DB wherever it's possible, you tend to just pass a few parameters across the network, transactions aren't held while you wait for network resources, and the whole thing goes like greased lightning. Databases should of course go in source control like any other source code.. there are plenty of tools for that.