A couple of thoughts sprung to my mind when reading Phil Factors reply to this editorial.

First was a design philosphy I always try to follow, which is to think re-usable. If you are desigining a piece of new functionality, ask yourself if you can forsee it being used in other parts of the system. Is it part of the business logic of your organisation that could be captured in a stored function or procedure. Much easier to change it then when the organisation changes it's business rules (these things occaisionally happen, like once a month 🙂 ).

Following on from this, think modular, if you are going to encapsulate some business logic in a function, make it as self-contained as is logically and physically possible given performance constraints. Supply it with the key values it needs to perform the process, and let it acquire any other the associated data it needs internally. This way your code presents a consistent 'surface' to the rest of your business system. It is far easier to change the internal operation of your functions and procedures when they are not over-reliant on the nature of the information passed to them. Otherwise you find yourself playing a sort of SQL Jenga, move one block, everthing else comes crashing down.

And on the subjects of the SQL Profanities, it is not the tools that are the cause of profanities, usually it is the workmanship that is done with them...

David