Craig-315134 (8/21/2013)
... I favour moving as much application business logic into stored procedures as is possible, thereby abstracting out the UI layer from the business logic. And our shop uses UDFs frequently as well as sprocs, so as to maximise our code reuse...
What I've typically seen is the following:
- application developers are focused on .Net or whatever their language is, and have limmited SQL knowledge
- few companies actually have separate database developers that do know the SQL side of things
- the DBA typically doesn't have the time to write all the stored procs that the application developers need
- proliferation of ORM systems and design methodoloy that say the database should just have CRUD operations
Basically when people are uncomfortable with the database side of things they don't want to put things there. A number of application developers view databases as either a necessary evil or even a hinderance to their work rather than an equal partner in things. They tell me as a DBA that there shouldn't be any business logic in the database, which I usually jokingly reply all they need then is 1 table with 2 columns, AttributeName, AttributeValue. 😀
My perspective, even when I used to be an application developer way back when, is that there really are 3 kinds of "business" logic: data logic, workflow logic, and interface logic. I then decide where code should go based on what needs to be accomplished, and try to right size things since .Net isn't good at working with sets of data, and the database isn't good at handling workflows and obviously doesn't have much user interface.