Apparently SQL Data Services (SDS) wasn’t at the point of no return today when the SQL Server Team announced that the REST interface for SDS would be abandoned in favor of SQL Server’s traditional Tabular Data Stream (TDS) transport and relational database management (RDBMS) features. This isn’t the mid-course correction that I wrote about on 2/24/2009, it’s now a mid-course reversal.
Leverage Your .NET, Visual Studio, SQL Server and T-SQL Programming Skills
What the SQL Server and SDS teams describe in their Next for SQL Data Services… and The no spin details on the new SDS features posts of 3/10/2008 is “SQL Server 200x for the cloud.” The Azure marketing folks have touted leveraging your .NET and Visual Studio programming skills as a primary selling point. SDS database design and programming techniques had little or no relationship to developers’ experience with RDBMSs, especially SQL Server and T-SQL.
Switching to a fully-featured SQL Server instance—or a reasonable facsimile thereof—lets the SDS team climb on the leverage your existing [SQL Server and T-SQL] skills bandwagon. Doing this also provides a service to compete directly with Amazon Web Services’ Windows Server 2003/SQL Server 2005 [Express] AMIs. It also lets Microsoft add a surcharge for SDS over Azure tables that’s “competitive” with Amazon’s US$ 0.60 or 1.20 per hour.
S[S]DS was built on a customized version of SQL Server 2005; here’s hoping that the new version will use SQL Server 2008, which enables “transparent data encryption, TDE” of sensitive/confidential data (Enterprise Edition only), supports spatial data types, and offers a raft of other useful new features. Whatever the SQL Server version the team chooses, it behooves them to make a CTP of the new SDS available sooner than “mid-2009.”
(Perhaps moving to TDS will enable the Azure or SDS Team to reply to my question about SAS 70 Audits for Windows Azure and SQL Data Services? of 3/9/2009. There’s obviously an issue regarding private encryption key management and accessibility.)
Update: Steve Marx replied for the Azure team on 3/10/2009:
We are in the process of evaluating various certification requirements relative to Windows Azure with a goal toward achieving key certifications by commercial launch or shortly thereafter.
But the reply is rather vague as to the specific question of SAS 70 audits.
Getting Azure Apps Closer to the Data by Abandoning SDS’s RESTful Inteface
TDS isn’t an Internet-friendly protocol; it’s intended to speed communication between front-end apps and back-end tables over a high-speed on-premises LAN. If you want to use SDS as a scalable data store for on-premises front ends with HTTP[S] access via TCP port 80 or 443, you must implement your own ADO.NET Data Services (Astoria) or SOAP data source. Hopefully Pablo Castro and the Astoria team will provide a pre-built REST data source with the features promised in Pablo’s Adding support for JSONP and URL-controlled format to ADO.NET Data Services post of 2/25/2009 and Mike Flasko’s Announcing ADO.NET Data Services v1.5 CTP1 post of 3/1/2009. However, it’s certain that SDS will connect to Azure Hosted Services more often by orders of magnitude than via the Internet to on-premises front ends. The latter was the original premise of SSDS (before MSFT announced Azure.)
Will It Scale?
It’s conventional wisdom that relational databases aren’t as scalable as the schemaless Entity-Attribute-Value (EAV) tables used by SSDS, original SDS, Amazon SimpleDB, and Google’s BigTable and the App Engine’s data store. If the SSDS team was leveling with us when they attributed the choice of the EAV (Authority-Container-Entity) data model to simplifying data access (not scalability), it could turn out that conventional wisdom was wrong in this case. What scares me is the problem of rolling out a schema update to a multi-terabyte database. As with most other issues of this type, time will tell.
David Robinson was right when he said in his SQL Data Services – What’s with the silence? post of 2/24/2009, “This time around we will be unveiling some new features that are going to knock your socks off.” I’m glad the SQL Server and SDS teams didn’t wait until MIX 09 to drop this bomb.
Stay tuned for updates until the other shoe falls.
原文: http://oakleafblog.blogspot.com/2009/03/sql-data-services-abandons-rest-for-tds.html