SQL Data Services: Look at Us Now!

Being the data and services geek that I am, I’ve spent a fair amount of time of over the last couple of months working with ADO.NET Data Services as well as the SQL Data Services portion of the Azure Services Platform.

SQL Data Services is built on top of the SQL Server technology we all know and love; however, the storage model that was exposed deviated a bit from the relational, schematized model that you would typically associate with SQL Server.  Namely, the model was a three-tier hierarchy known as ACE, an acronym for “authority”, “container”, and “entity.”  In this model, there’s no real direct analog of a ‘relational table,’ and entities, which you can sort of think of as relational table rows, contained just a bunch of properties that may or may not have correlated to properties of other entities of the same ‘kind’.  The upshot of this is that moving your on-premises solution using SQL Server to a cloud solution using SQL Data Services would result in a fair amount of rethinking and retooling your data access strategy.

Well, that was then, this is now.  The SQL Data Services team has just announced a major new milestone in the technology.  We’ve said all along that the ‘flexible entity’ approach would evolve to include more and more relational capabilities of the core SQL Server functionality.  Well, evolve it did and quickly!

From the announcement today:

We … have added to the mix true relational capabilities, T-SQL and compatibility with the existing developer and management tools ecosystem.

What does this mean for developers? Developers will be able to very easily provision themselves a logical server and database and begin developing against it immediately using the existing tools and technologies that they are accustomed to. We are providing an experience where a developer can take an existing application and just change the connection string to point it to the cloud and have it just work.

How will we do it? Three letters TDS. TDS stands for Tabular Data Stream and it's the published protocol that clients use to communicate with SQL Server. From its inception, SDS has always been built on the SQL Server technology foundation and it just made sense to allow our users to access their data via TDS. Most importantly for developers, this means symmetric SQL Server functionality and behavior combined with compatibility with the existing tools you are familiar with.

Tables?...Check

Stored Procedures?...Check

Triggers?...Check

Views?...Check

Indexes?...Check

Visual Studio Compatibility?...Check

ADO.Net Compatibility?...Check

ODBC Compatibility?...Check

This is a pretty awesome development in my opinion.  It helps to clarify the differences between the old ACE model and Azure storage, which was often difficult to articulate.  More importantly though it provides a much more seamless ‘migration’ path for taking existing on-premises applications to the cloud with Windows Azure, and just removes a potential barrier to adoption.

Make sure you tune into all the announcements coming up next week at MIX as well.