Reputation: 2207
I have to choose which way I should create new application: Client-DataBase (with business logic implemented at stored procedures) or Client-Server-DataBase (where business logic is implemented at server side, leaving stored procedures with just data representation functions).
Today there exists stored procedures, that allows to create DB very smart, and argument "client shouldn't have business-logic" is not good: with stored procedures it may not have much of business logic. What for should I create server? Or I don't need it and should try to implement as max as possible on stored procedures side?
If I need to contact many DB's, with server I may do it by async connections. With DB variant I may do it with dblinks (and even also async, as I understand).
Is it question of preferences, or there exists architecture needs and logic that I don't see yet?
Upvotes: 0
Views: 191
Reputation: 9473
Most modern applications make their databases as dumb as possible. Kicking logic out of them makes an application much more scalable, testable, and portable.
Putting business logic into stored procedures means you must scale your application vertically by making larger and larger databases to support it.
Testing stored procedures is notoriously difficult and expensive compared to testing a standalone business logic layer.
It also tightly couples you to a single database provider.
If none of these are concerns, then putting all of your logic into a stored procedure may be a viable solution. I've never seen a stored procedure based application that wasn't a mess. I'm not saying they are inherently evil, but I almost always see them misused, and the resultant ball-of-mud application is usually a scrap-and-rewrite sort of affair.
Regardless, do some reading:
http://c2.com/cgi/wiki?StoredProceduresAreEvil
http://ask-beta.slashdot.org/story/04/07/30/2324206/stored-procedures---good-or-bad
Upvotes: 2