My friend
Azam just hit a nerve. One of my pet peeves is the fact that some people clutch to stored procedures and claim it to be the
one place to hold the true state and logic of a system. I have worked with such a DBA, and it was not very fun.
Anyway, he makes the claim that it is easier to make a tiny change to a stored procedure than to make the change in code, recompile, and upload the new version of the application to the servers. He gives this example:
Let's say that you have some code to display all the users who
enrolled within the past 7 days. You implement it using some OR Mapper
and the domain contains the logic for pulling out the users enrolled
within the past 7 days. Everything worked fine! Now, the client comes
and ask you that he needs to view the users enrolled in the past 14
days (Let's assume for the sake of discussion that we don't have the UI
to select the number of days). Now, you have to change the code in the
domain model and then upload the new version of the application.
I have to disagree. While the impedance to making a change is usually smaller by updating a stored proc, a change is a change is a change.
Most production enviornments I have worked in are guarded by a machine-gun weilding fairy with a SOX t-shirt on that won't let me run an innocent little script without getting the blood of 14 virgins and my manager's approval. So sometimes the actual process of making a change overshadows the change itself.
2nd, when the next developer goes to review the code, shouldn't he/she know EXACTLY where the business logic is? I would argue that the largest cost in this scenario is the maintenance cost of the poor developer who doesn't know where to look for a change. It could take an entire day of searching to find out exactly where that rule is being defined.
If the value in question (the number of days) was identified to be a possible changing value, then place it in a config file so that the application can change on the fly without having to jump through burning hoops of fire.
Anyway, like I said, this is one of my pet peeves, so if you enjoy working with elegant software, don't put logic in your database. Keep it in your domain layer where it belongs.