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).
In reply to Re^2: Moving SQL from perl to Stored Procedures
by jhourcle
in thread Moving SQL from perl to Stored Procedures
by imp
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |