At just about every talk I give I always try to make several consistent statements. One of which is: ‘Whenever possible use stored procedures to access your data’.
Let me start by stating some disclaiming remarks. I'm not against stored procedures in general, I find that the choice why procedures should be used, should be based on proper facts, not on claims without any proof.
My CIO and I have looked at a number of commercial solutions for documenting Sarbanes-Oxley compliance. However, we decided to use SQL Server 2005's built-in tools to create our own "home-grown" auditing system.
Healthcare applications come and go, but data live on forever. We’ve seen that since the beginning of the computer industry; when we move from legacy systems into more “modern” architectures, we often leave behind applications, but we almost always take along the data into the future. Even though data are so important, we in health-IT don’t seem to spend the quality time necessary to structure our schemas and databases in such a way as to make it easier to maintain in the future. We often don’t design our data models solidly, and we don’t test them well by putting them through simulations or design them for multiple versions.
Rules play a central role in a wide variety of applications. In addition to the declarative specification of business rules, the simple rule engine design described in this article can be used to implement state machines, predicate dispatchers, or any other rule-based system.