SQL Server Worst Practices

March 15, 2009

I am by nature skeptical of best practices. An organization in financial trouble or under a legal storm cloud is not a candidate for a best practices write up in my opinion. I saw a link to an article called “SQL Server Worst Practices” here. The information was compiled by the consulting firm, Edgewood Solutions Engineers. My hunch after reading the write up was that the Edgewood folks wanted to offer some tongue in cheek commentary on two thirds of the IT departments’ favorite old style Codd database, Microsoft SQL Server. The impact on me was different. I did not find the 13 worst practices very amusing. Let me highlight three worst practices and then offer my view on why these did not tickle my funny bone. Keep in mind that I am an addled goose and have an insensitive funny bone. My picks from the 13 items:

Worst practice 11 “No referential integrity”. The problem is a lousy data model. From that devolves problems with referential integrity. Get it wrong and spends lots of time reinventing your wheel. Common, expensive, and careless.
Worst practice 8 “Throwing hardware at the problem”. The idea is that Intel’s hottest CPU, lots of cheap RAM, and SATA will make up for choke points in reading and writing data to the RDBMS’ tables.
Worst practice 2 “Not verifying SQL Server backups…” The assumption is that back ups work. In my experience, back ups don’t work that well. The fancy dancing turns into clumsiness when data are lost.

Why did I not find the 13 worst practices amusing? In search systems from a certain large vendor in Redmond, the beastie SQL Server lurks. After many years of effort, SQL Server is commonplace. Along with its ubiquity are problems in performance, back up and restore, and integration issues with other enterprise systems including Microsoft’s own trailer park of servers, among others. Think weird latency. Think complexity with the scale up and out.

This checklist reminds me why the RDBMS model is not the peppiest geriatric at the Senior Center. Time to move on. Databases are yesterday. Dataspaces are where one should look.

Stephen Arnold, March 15, 2009

Written by Stephen E. Arnold · Filed Under Database, News, Technology

Comments

Comments are closed.

Search the site
Subscribe to Beyond Search
Feature archive
News archive

Stephen E. Arnold monitors search, content processing, text mining and related topics from his high-tech nerve center in rural Kentucky. He tries to winnow the goose feathers from the giblets. He works with colleagues worldwide to make this Web log useful to those who want to go "beyond search". Contact him at sa [at] arnoldit.com. His Web site with additional information about search is arnoldit.com.