Re: Moving SQL from perl to Stored Procedures

Stored procedures *shakes head*.

Any university student will know that dividing application logic between application and SQL server is messy at best. It's a direct violation of the principle of cohesion which seeks to keep related logic together.

Indeed, the principle of coupling is also attacked using stored procedures.

I see industry racing to use these "cool ideas" but in reality so many of them are unsound. Too many cowboys in industry..

Comment on Re: Moving SQL from perl to Stored Procedures

Replies are listed 'Best First'.
Re^2: Moving SQL from perl to Stored Procedures by jhourcle (Prior) on Sep 09, 2006 at 20:12 UTC
You're looking at it wrong -- we're maintaining coupling in the database -- I'm keeping the data with its associated logic. Should I leave the data to be misinterpreted by each application's programmers? Should data security be moved from the database and to the application? Should each application implement the same accessors or business logic? (remember -- they might not all be using the same programming language) Any person with experience knows that every situation is different, and there are advantages and disadvantages to almost every method. There may be times when it makes sense to keep all of the business logic out of the database (eg, you have reason to believe that your company may be switching database vendors in the future, and you'll have to re-code all stored procedures), and there are times when keeping it all close to the database makes sense (eg, it's a large database that's used by multiple applications, and you need to keep applications from making calls that might adversely affect the overall performance of the database).	[reply]

Replies are listed 'Best First'.

Re^2: Moving SQL from perl to Stored Procedures
by jhourcle (Prior) on Sep 09, 2006 at 20:12 UTC

You're looking at it wrong -- we're maintaining coupling in the database -- I'm keeping the data with its associated logic.

Should I leave the data to be misinterpreted by each application's programmers?

Should data security be moved from the database and to the application?

Should each application implement the same accessors or business logic? (remember -- they might not all be using the same programming language)

Any person with experience knows that every situation is different, and there are advantages and disadvantages to almost every method. There may be times when it makes sense to keep all of the business logic out of the database (eg, you have reason to believe that your company may be switching database vendors in the future, and you'll have to re-code all stored procedures), and there are times when keeping it all close to the database makes sense (eg, it's a large database that's used by multiple applications, and you need to keep applications from making calls that might adversely affect the overall performance of the database).

[reply]