Hatin' on the database
I know the cool kids aren't even using a database (well an RDBMS anyway) anymore, and the debate rages about why new approach X isn't up to par (when often those new approaches are better, depending on the context), but sometimes - especially in the "Enterprise" - the database is still appropriate, or is still "required" appropriate or not.
I think one of the best guys to explain how you should treat a database in terms of development processes is Scott Ambler. I have seen him give a few tech talks now and again and every time he is engaging and informative - if a bit blunt (which I personally appreciate). One of his tenets is that databases should be treated like other artifacts during development.
You know what that means, right? It means tests, TDD, refactoring, and checking the database source into source control. Now if you are shaking your head or scowling, or are perplexed, you aren't alone, but you do need to get with the program. In fact, I have *never* worked with a company/data team that had a test, or used SCM, but it can and *should* be done as Jeff Attwood also notes:
When it comes to version control, the database is often a second or even third-class citizen. From what I've seen, teams that would never think of writing code without version control in a million years-- and rightly so-- can somehow be completely oblivious to the need for version control around the critical databases their applications rely on. I don't know how you can call yourself a software engineer and maintain a straight face when your database isn't under exactly the same rigorous level of source control as the rest of your code. Don't let this happen to you. Get your database under version control.
Generally what I have done, to try to make the best of it when data is out of my control, is worked through a data access layer that can be tested/refactored, etc. This though, in my experience, has always led to a lot more time and money being wasted, because of the added complexity and process that has to go into covering up the database warts.
In many places I have worked the mentality seems to be that the database is written in stone (and all we can do is ADD something to it somewhere, but not refactor it to do it right). This is a horrible, costly, gigantic mistake. (Which I have tried in my own Quixotic way to convey in many places - but have usually failed to change for many political and or ignorance related reasons.)
If you have influence and or control, on any level, for the love of Pete, look more into agile database practices (if you don't already employ them). For more on "Agile" and data, see Scott's works, such as Refactoring Databases, and or the tons of free resources on the fantastic AgileData.org site.
