Editor's Note: SQL Server Magazine welcomes feedback about the magazine. Send your comments to letters@sqlmag.com. Please include your full name, email address, and daytime phone number with your letter. We edit all letters and replies for style, length, and clarity.
The Pain of Poor Database Design
Jeffrey Bane's article "The First Abnormal Form" (August 2001) is what I consider a "carry around" article. I'll carry it around as proof that poor database design is usually the root of performance problems. As an independent consultant working mostly with SQL Server and Oracle database design, maintenance, and redesign, I found the article invaluable.
In the SQL Server environment, I'm running into a recurring problem. I'm finding small to midsized companies that have given the database-design job to the Visual Basic (VB) or C++ programmer. SQL Server is very easy to install out of the box (as opposed to Oracle, which someone without experience simply can't install). So, companies think that if SQL Server is easy to install, it must be easy to design. Why hire someone new when your VB person can do the job, right? And of course, the VB person is willing to learn a new skill while continuing to perform his or her main duties. But the results can be disastrous. Ever seen a 300-table database in which all the data types are varchar(255)? Dates, numbers, dollar amounts—you name it, it's a varchar(255). Not a pretty sight.
—J. Jeffrey Schwartz
jjeffreyschwartz@earthlink.net
Thanks for your comments, and let me say that I feel your pain. In my opinion, SQL Server's ease of installation and administration both helps and hurts the product. Sometimes I wish Microsoft would make SQL Server more difficult to install and administer (like Oracle) so that people would understand that database development and administration is a serious task. But on most occasions, I find myself thanking Bill Gates that SQL Server has simplified most operations so that we can spend our time addressing the more important and time-consuming database tasks, such as proper database design. As to your main point, I don't know how we can spread the word that database design is actually a genuine skill that requires a qualified, experienced professional. I think your letter is a good start!
—Jeffrey Bane
I enjoyed Jeffrey Bane's article "The First Abnormal Form" (August 2001). Too many times in the past, I've been stuck supporting someone else's table design only to find problems just like Bane described. I found the article to be well written and thought out until the section about "Abbey Someone." Table AB2 suffers the exact problems (except for the data-retrieval issue) that Bane was trying to eliminate. I'm not sure what the article's stored procedure was trying to accomplish, but a much simpler way exists to populate the drop-down list. I would have created the SELECT statement to return one record, then used the Split() function and a For..Next loop to mimic the Do While in the article's Active Server Pages (ASP) page, as the code example in Listing 1 shows. No stored procedure and a simpler ASP page would have done the trick.
—John Hembree
jhembree@isoc.net
Thanks for your input. I don't think I've ever received so much feedback about an article before; it seems that quite a few of us are having to deal with tables in the first abnormal form. You make an excellent point that the Split() function, as your example shows, would work nicely. In this article, however, I wanted to stress the complexity involved when using T-SQL to deal with comma-separated strings. Most DBAs have enough to worry about without having to master VBScript. Most traditional languages do have a richer set of commands for dealing with string operations than T-SQL does. But no matter what language you use, if your database isn't properly normalized, you're going to be doing more processing than necessary.
—Jeffrey Bane
Prev. page
[1]
2
next page 
