Using Databases

As you advance your career, you learn things. Some of these are insignificant, and some are monumental, should-be-carved-in-stone-for-all-to-see important. Here is one of my 'programming truths'. It's mine, remember, not everyone will agree.

Databases are for storing data. Period.

They are not for writing code, they are not for manipulating data. There are big boxes in which you can put your data. I'll allow them to index that data, but not much else.

A few years ago, I realized once and for all the stored procedures were evil. They were a pain to maintain, and generally unnecessary. And a year ago, I swore off the crutch that is 'identity' columns or 'auto-increment' columns for creating primary keys. Yes, these things are terribly convenient... but they can cause serious havoc later on if you are migrating to a different database engine, or (more likely) combining two databases into a single instance.

And since I just discovered a bug in MSSQL 2005 which relates to Identity columns, I've found another reason to despise these datatypes. (http://support.microsoft.com/kb/952111)

So. Take my advice, I know of which I speak, and use databases for storage, put your data manipulation code where it belongs, in your data access layer. You will thank yourself for that decision in the future. I promise.