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.
About 2 weeks ago I heard of a SQL Server training event held on a cruise ship. Huh? What? A cruise ship….my curiosity led me to SQLCruise.com to read all about it. The more I read the more excited I got about going, so I consulted the checkbook and the Hubby, got the green light to go, and signed up!
Just 78 days until we depart. I can’t wait!
Too many Server and Login Names cluttering up you “Connect to Database Engine” dialog box in 2008? Do you want it to look like this again:
Do a search on “SqlStudio.bin”. It will be under …\Application Data\Microsoft\Microsoft SQL Server\100\Tools\Shell\SqlStudio.bin. Close down SSMS, rename the file and start up SSMS again. Now those boxes are nice and clean for you!
For SQL Server 2005 directions, go here
I’m continuing to make my way through this book, although far more slowly then I would like. If you missed the first part of my review you can find it here.
Chapter 6 – This chapter focuses on using graphics such as charts and images in reports. This chapter provided a nice overview of graphics, and like the previous chapter, the directions were easy to follow. I’m not sure if I will use graphics to build reports in my current job, none of the reports we have in production include charts and we have very little use of images.
Chapter 7 – This chapter is called “Kicking it Up a Notch: Intermediate Reporting” and that is a perfect title for it. The chapter starts with showing how to create a template to use in future reports. Much time is spent on improving the presentation of reports and the chapter introduces concepts like totals in reports, grouping, sorting, parameters, and using stored procedures instead of SQL queries. Lots of meat here and it took me a bit of time to build all the reports in this chapter.
And I can’t remember any typos, not a one! The only criticism I have is this: stored procedures should be introduced earlier, maybe even in chapter 5. Embedded SQL in reports (or applications) is not a good thing.
So far, a very good book, well worth my money.
The other day I was looking up some information about SQL Server Profiler and I came across this book “Mastering SQL Server Profiler” by Brad McGehee. It is in PDF format, so I downloaded it and opened it up to take a look. 306 pages. Oh my! On just Profiler alone! Then I grabbed another book, “SQL Server Execution Plans” by Grant Fritchey. This one was 181 pages! And my Reporting Services book tops those two at 866 pages.
Ten years ago, when I started my first job in the database world, working with SQL Server 6.5, I could not have imagined the volume of information dedicated to SQL Server. Back then, a whole book on the product was only 400-500 pages. The product has grown so much that no one person could know it all. Even the people considered the most knowledgeable about SQL Server typically specialize in just a part of it. That’s probably why I have over 25 different SQL Server blogs in my RSS reader. No one blog covers it all.
I have to remind myself to focus my self study efforts. I have to partition out all the things I would like to know about SQL Server into two buckets: stuff I need in my head and stuff I should just know to how to look up. It’s less stressful that way.
