An Interview with Louis Davidson author of 'Professional SQL Server

2000 Database Design'(Posted by Jon Winer, interview was provided by Wrox)

1. What first inspired you to get involved in database design?

Actually it was less inspiration and more chance. I was working as a LAN administrator for the Church of God International Headquarters in Cleveland, Tennessee, and not doing the greatest job. I still had a year left on my degree at the University of Tennessee at Chattanooga and really wanted to do some programming. We were spending tens of thousands a month on a mainframe system that was really wasting our donor’s money, and needed to find a way to be more cost effective. A fellow named Michael Farmer and I really pushed to replace the system with something smaller and cheaper and chose to do a client server system using Microsoft's SQL Server product since it was really inexpensive. When the programmer that was hired to do the stored procedure and trigger development left, I was drafted in to replace him and finish the task of hand coding 800 stored procedures and triggers. The rest is history, really boring history…

2. Could you tell us a bit about your background in database systems?

It all started in a class that I had at UTC in database design. I made a marginal grade, but the teacher (Dr Fred Thompson) really made a good impression on me. Then the experience of writing procedures and triggers really helped to solidify that databases would be my career for quite a while.

I have to admit one thing though, the thing that has helped me out more than anything is that all of my meaningful programming experience has been in building database applications. These days I generally have a hard time writing code in VB or any other non relational language because it goes completely against the way that I think.

The people I have worked for (though not always those that I have worked with 🙂 have totally believed in proper database structure. Even in the early days of SQL Server when hardware was abysmally slow and the database technology had not been fully fleshed out, we still used proper normalization techniques to avoid many of the pitfalls I endeavor to outline in my book. Proper normalization is the database equivalent to proper modularization, and when I have gotten lazy it is has cost me in later modifications. One thing that most programmers and especially managers generally fail to understand is that if a project is done right the first time, the future costs of maintenance are generally far less than if you cut corners during the first version.

3. Do you enjoy logical design more than physical design or vice versa?

What I actually enjoy are video games 🙂 To that end my preference is logical design, because I prefer to make sure that the foundation of a system is solid. Once the logical design is done well, initial implementation tends to be more straightforward and future modifications are generally easier -so I end up with more time for video games!

I think, however, that my favorite part is coding and optimizing complex queries. There is something really satisfying about taking a requirement, a normalized set of tables full of raw data and turning that into information that a user needs. This tends to fill the rest of my time as I have yet to work for an organization where I can play video games all day, and games seldom require relational databases, though I do live in hope:)

4. What do you think are the key issues that novice designers should take on

board from your book?

Understand all of the whys that surround what you are doing or trying to do! Why do we normalize? Why does SQL work the way it does? Why do they store data the way they do? Why does the optimizer choose a given plan? In Professional SQL Server 2000 Database Design I give some basic insight into the “whys” of database design, there is so much to learn that it couldn’t be covered in detail, but I try to pepper the book with references to additional resources to look into.

Once you understand the “why”, you can more easily accept or reject common practices. There are no binding reasons to follow any of the techniques that are currently agreed upon, but SQL Server was built based on a certain set of theories, and generally works better when these are followed. It is likely that readers will disagree with some of the content in the book, and I actually hope this is true. The more you question the more you try out and the more you learn. I appreciate that my techniques and opinions are not definitive answers, but as is true with any technical topic, you need to understand the fundamentals of a concept before you disagree with it.

5. You discuss client interviews in your book, what do you think are the

most important points of such an interview?

Don’t forget the people who do the actual work, as they have most of the system knowledge that you will need. It is not an overstatement to say that the most powerful person in an organization is usually the assistant to the person in charge.

The other point is to listen carefully to everything that your interviewees have to say. Most of the people who we need to interview have great ideas, but have little concept of how the final system should be structured, or even the final set of features or requirements. With careful listening, coupled with an occasional lead in the right direction, most notably to drill down on a particular thought, it can be amazing how much information can be gotten from client interviews.

Often you will discover problems that go beyond the scope of your current project, and at the very least be certain to get desires and concerns documented, regardless of whether they are used in your current project or simply noted for later use. As long as you don’t give any false hope to the interviewee (like you are going to be their personal savior) and you manage the scope of the project, by documenting client issues you may even end up with future work (which is especially great if you are a consultant!)

6. What issues do you think will be making waves in the near future for database designers? (With an eye on evolving web services?)

Not really sure that I can answer this one in any kind of depth. I am kind of lost in some ways in that I have really focused on relational databases and to a lesser extent user interfaces, for the entire time I have been programming.

However, the most important topic that seems to be cropping up more and more is XML. Every tool that is being developed these days seems to be using XML formatted storage to save and share data. I fought with myself long and hard trying to decide whether or not to add XML information to the book, in the end I decided to leave it out since it did not seem to me to really drive design issues. The new XML support in SQL Server 2000 looks pretty cool though

7.What do you think makes this book stand out from others on the market?

The picture on the cover. I really expected Wrox to replace my picture with an animal of some sort, perhaps a bullfrog. I think a bullfrog of some sort might have driven sales through the roof!

But seriously, I have tried to cover some of the subjects that tend to get overlooked, like Fourth Normal Form and Relational Theory. In the physical section of the book the goal was to expand greatly on topics that are generally never totally covered, like datatypes, and coding server objects, using a lot of examples but without wasting a lot of time explaining how the SQL Server GUI was used. I also tried very hard to not duplicate the SQL Server Books Online to keep the book as small as possible, so that we did not waste time covering material that was easily accessible. Those types of books already exist and are great resources, but I wanted to go a different way and explain more about how the most important SQL Server mechanisms could be used and largely ignore things that have already been heavily trodden in other books. This is especially true of system administration facilities, as when designing a database these things do not matter a great deal. 

Want to find out what others thought of Louis' recent book, check out our review of

'SQL Server 2000 Database Design'.