Join me as we peer into the thoughts of a developer who has just received a freshly minted SQL Server 2005 CD-ROM sometime in the future: "The row size in SQL Server is expanded! I can now put my entire database in a single XML column in a single row and query it through XQuery. You can index the native XML data type, so performance is bound to be great! Our project has a tight deadline, and think how much faster the developers can work if they don't have to deal with those darn stored procedures and inferior T-SQL code. Done! One row, one column—how cool!" Laugh if you want, but don't doubt that otherwise sane and rational developers will be tempted by the allure of this scenario. One row and one column might be over the top, but developers will unquestionably end up using XML in places they shouldn't. Be honest, you know at least one developer who thinks it would be cool to have that one-row, one-column database.

"What's the big deal?" you might ask. In a battle to protect the integrity of databases around the world, the mighty DBA will fight to the death to protect life, liberty, and the pursuit of normalization. But many development shops don't have a full-time DBA who considers it his or her sworn duty to think about and protect data. Fortune 500 shops still have that luxury, but many medium-sized businesses assign database-design tasks to their development team. One or two people, often with little or no database experience, end up being the database keepers.

Two weeks ago, I went out on a limb and suggested that most database developers don't spend enough time on formal data modeling, but that this lack of effort didn't usually create major problems (see "Data-Modeling Tools Aren't Physically Fit"). I might have to change my stance with SQL Server 2005's release. More so than any previous release, SQL Server 2005 includes features that, if implemented incorrectly, can seriously affect your system. Misuse of such new features as the Common Language Runtime (CLR) and the XML data type can hurt the SQL Server engine's ability to perform efficient data access. Poorly designed data models might begin to cause a significant share of performance and application-logic problems. Storing XML data in the database is the right thing to do from a Microsoft tool developer's perspective. But SQL Server community leaders and Microsoft, through its Patterns and Practices initiative and other materials, need to teach developers how to use XML—and how not to use it.