For the past 6 weeks I’ve been attending a civilian “Boot Camp”, an fitness program designed to help you lose weight and get in shape. With this program comes the requirement to write down everything you eat in a food journal. Oh, how I have hated keeping this food journal, it is harder then the daily exercise sessions. Why do I want to remember what I ate last week if a lot of it was junk?…but that’s just the point. If you write your food choices down you are more likely to pick healthy food, not junk. Keeping track of my eating habits in a journal has given me insight into my eating habits and how they affect my health.
So what does this have to do with documenting our databases? Well, in my experience the worst databases I’ve come across have the least amount of documentation, in some cases, none. If you are throwing hacks into your database, you just want to purge the whole event from your mind, not write it down. We don’t want to remember the hack we had to put into the database or the fact we really don’t like the all the other “junk” that the last developer/DBA put into the poor database either.
But like your diet, the worse the database is, the more it needs documentation. Like the improvements in our bodily health, improvements in our SQL Servers will be much easier to come by if we take the time to document what we’ve got, as junky as it might be. But don’t try to document the whole thing at once. My food journal only asks for what you ate at your last meal or snack, not your food choices for the past month. A little bit at time makes it more likely that you will actually do it. So document your databases as you go, a small portion at a time. That way it won’t feel like such a chore.
