Question

For typical 3-tiered application, I have seen that in many cases they use a lot of complex stored procedures in the database. I cannot quite get the benefit of this approach. In my personal understanding, there are following disadvantages on this approach:

1. Transactions become coarse.
2. Business logic goes into database.
3. Lots of computation is done in the database server, rather than in the application server. Meanwhile, the database still needs to do its original work: maintain data. The database server may become a bottleneck.

I can guess there may be 2 benefits of it:

1. Change the business logic without compile. But the SPs are much more harder to maintain and test than Java/C# code.
2. Reduce the number of DB connection. However, in the common case, the bottleneck of database is hard disk io rather than network io.

Could anyone please tell me the benefits of using a lot of stored procedures rather than letting the work be done in business logic layer?

Answer 1

Basically, the benefit is #2 of your problem list – if you do a lot of processing in your database backend, then it’s handled there and doesn’t depend on the application accessing the database.

Sure – if your application does all the right things in its business logic layer, things will be fine. But as soon as a second and a third application need to connect to your database, suddenly they too have to make sure to respect all the business rules etc. – or they might not.

Putting your business rules and business logic in the database ensures that no matter how an app, a script, a manager with Excel accesses your database, your business rules will be enforced and your data integrity will be protected.

That’s the main reason to have stored procs instead of code-based BLL.

Also, using Views for read and Stored Procs for update/insert, the DBA can remove any direct permissions on the underlying tables. Your users do no longer need to have all the rights on the tables, and thus, your data in your tables is better protected from unadvertent or malicious changes.

Using a stored proc approach also gives you the ability to monitor and audit database access through the stored procs – no one will be able to claim they didn’t alter that data – you can easily prove it.

So all in all: the more business critical your data, the more protection layer you want to build around it. That’s what using stored procs is for – and they don’t need to be complex, either – and most of those stored procs can be generated based on table structure using code generation, so it’s not a big typing effort, either.