I came across this database tuning guideline and thought it was really interesting. Even though it's written for Oracle, there are quite a few items that apply to SQL Server as well.

I scan through the forums here at SQLServerCentral on a regular basis and I see hundreds of performance related questions posted every week. That's both good and bad, but the concerns that I see are that there are many of the same types of questions posted over and over. To me that indicates that people new to SQL Server aren't being trained very well or that too many people building applications aren't concerned with the basics of good design.

The top 2 items in the guideline are "Start with the data model" and "Tune the SQL". Unfortunately too many people want to dig down into the hardware or SQL Server itself, not their code. I see many posters, most often Jeff Moden preaching how much better things work when you build them right the first time. Jeff often tries to get people to learn how to write better SQL, and then do it from the start! We all appreciate Jeff's help as well as that of many others who post here every day.

My guess is that most of the problems in code can be traced to poor data models or poor coding from the start. In fact, I'm amazed at how poorly some data models are in packaged applications. I realize that these companies are in a hurry to get their products built, but you'd think that they'd consult a DBA at some point.

Every time I hear about how DBAs tend to be arrogant and difficult to work with, I sympathize a little because I know I've been like that before. But as the guardian of the company's data, I think it's important to maintain control and enhance stability. I also think it's better to write a little more code than hope hardware keeps up.

However having dealt with a few developers at some software vendors, I wonder if DBAs aren't actually easier to work with. I've had quite a few of them show me models that were highly flawed and inform me that things worked well, despite not having any arguments against improvements I pointed out.

Do yourself a favor and try this technique the next time you go to design something or write some complicated SQL. Spend an hour thinking about your design, then take a break for at least an hour. Then go talk to a friend, co-worker, fellow DBA, someone that understands the process and spend an hour working through the design and looking for flaws.

Chances are you'll find some, and then you can build a better system from the start.

Steve Jones

The Voice of the DBA Podcasts

The podcast feeds are now available at sqlservercentral.podshow.com to get better bandwidth and maybe a little more exposure :). Comments are definitely appreciated and wanted, and you can get feeds from there.

• Video Podcast - 10.5MB Quicktime
• Audio Podcast - 6.3MB MP3

Today's podcast features music by Robin Stine. She's got a great blues, jazzy feel, so support this artist at www.robinstine.com.

I really appreciate and value feedback on the podcasts. Let us know what you like, don't like, or even send in ideas for the show. If you like it, tell the boss!