Database Design with an Expiration Date

Posted: February 21, 2010 in Uncategorized

What a week last week. There was so much that I needed to do and I spent most the time falling behind. The highlight of my week was speaking at the Denver SQL Server User Group. What a great group that they have there, but that is a whole different subject. My presentation was on the mistakes that I have made over my career and as I explained during the session, the mistakes were not to be looked at as specific incidents but more of a general idea. For example we talked about a job that I had at one point where a couple of errors were made with a RAID 5 drive. This error was what caused a problem, but the other issued that surrounded that issue were what we talked about. Items like how you manage the error, or manage the notifications and the way you treat staff or even the way you are treated.

At the end of the group one of the attendees (I am so sorry I don’t recall his name), mentioned to me something that I thought was a great insight. He said that many databases have expiration dates; the problem is that it’s just not printed on the label like milk. The comment was based on the point that I had made during the session that you should not build limits around the database that you are designing. The idea or the thought that your database will never grow that big or have that many records or be around that long is just foolish. No matter what way you look at it the way companies are looking at the technology debt they are willing to take on it is obvious that band aids to fix issues is not enough anymore. There are too many people that are looking at database designs and are now saying “we know it sucks, but it will work for now”.

Does this mean that everyone should re-design every time? No. It means that we need to make sure that we understand where the limits are on the systems that we run and what we can do to not reach that expatriation date. If that means you have to re-design then you have to re-design.

An Example? What about a database that was designed for a few users, there were few tables and a lot of information was stored in those few tables. As the database as grown and development has progressed with the business it is obvious that these few tables need to have some more separation. It could be revalidating that the table is in third normalized form, it may mean that you need to add table partitions. Then end result is don’t end up in the position where you have to wait until there is a problem before action is taken.

If there is a problem then you are too late.

I find this interesting since the SQL Perspectives chapter review relates to this from last week and Jeremy Lowell just posted a blog entry about it.

If you missed that session and you want to see it I will be delivering it in Denver at the Rocky Mountain Tech trifecta on Saturday. If you look at a few of the older posts here on the blog you will see a place to register. It is a free event so why not? There are going to be a lot of great speakers there.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s