architecture - Client to DB vs Client to Server to DB -

architecture - Client to DB vs Client to Server to DB -

i have take way should create new application: client-database (with business logic implemented @ stored procedures) or client-server-database (where business logic implemented @ server side, leaving stored procedures info representation functions).

today there exists stored procedures, allows create db smart, , argument "client shouldn't have business-logic" not good: stored procedures may not have much of business logic. should create server? or don't need , should seek implement max possible on stored procedures side?

if need contact many db's, server may async connections. db variant may dblinks (and async, understand).

is question of preferences, or there exists architecture needs , logic don't see yet?

most modern applications create databases dumb possible. kicking logic out of them makes application much more scalable, testable, , portable.

putting business logic stored procedures means must scale application vertically making larger , larger databases back upwards it.

testing stored procedures notoriously hard , expensive compared testing standalone business logic layer.

it tightly couples single database provider.

if none of these concerns, putting of logic stored procedure may viable solution. i've never seen stored procedure based application wasn't mess. i'm not saying inherently evil, see them misused, , resultant ball-of-mud application scrap-and-rewrite sort of affair.

regardless, reading:

http://programmers.stackexchange.com/questions/65742/stored-procedures-a-bad-practice-at-one-of-worlds-largest-it-software-consulting

http://c2.com/cgi/wiki?storedproceduresareevil

http://ask-beta.slashdot.org/story/04/07/30/2324206/stored-procedures---good-or-bad

architecture