You may disagree with the title of the post, but I think it is far more true than not. First, because I know folks are going to try to tell me, this doesn't apply if you're using S[S]DS (SQL Server Data Services), once it finally becomes available because it really is nothing more than SQL Server running on MS machines in the cloud. This is, of course, the same as if you were running SQL Server on Amazon hardware. But there's a major problem with SQL Server when it comes to scalability above a certain level, most of which I covered in Why Aaron Skonnard is Wrong About Azure Table Storage. And all of the things that make SQL Server bad for highly scalable web sites are the things we know as DBAs.

For instance, if you've ever heard Kimberly Tripp speak about database design, you've probably heard her mantra about clustered indices being "monotonically increasing values" (Identity Columns) because SQL Server is built to handle those especially well as clustered indices. That's all well and good but Azure Table Storage, while it may be using SQL Server as a back end processor, doesn't care about Identity columns and ATS certainly doesn't support them. If you want to create Identity columns you'll need to roll your own. But I wouldn't recommend it because it creates a choke point, and creating highly scalable data means avoiding those.

Take all of the best practices related to building indices for SQL Server to support JOINs. A great feature of the current SQL Server is the ability to create covered indices without including the covered columns in the actual index. ATS doesn't support JOINs so covered indices are out.

Any of the many tips and tricks we've learned over the years in working with SQL Server related to writing stored procedures are out because ATS doesn't support stored procedures.

Take a look at Microsoft's SQL Server Best Practices page. Almost everything there is very SQL Server specific and wouldn't apply to an Oracle database or an Informix database. Which is why none of these will apply to ATS, because ATS is not SQL Server. Not only that, many of the rules of Normalization do not apply to ATS because Normalization applies to Relational data and ATS is not relational.

In a very Zen-like way, we need to discard almost everything we take for granted as knowledge about how to work with data and re-focus on the data itself, how we can work with it and what we need to do with it. Not only that, Azure DBAs are going to need a much bigger chunk of .NET programming to be able to handle the tasks ahead of them.

Scalable data requires rethinking our expectations and a huge paradigm shift. I'm going to be working through a lot of the issues related to Azure Hosted Services and Azure Storage on my new site: AzureDBA. It'll be going live in the next week with most of the thoughts from the Azure postings I've done here along with sections on best practices for all aspects of scalable cloud computing and any new thoughts I come across as I continue to work with and explore Cloud Computing with Azure.