Why does the SQL Data Services (SDS) not adopt to the RDBMS model which the SQL Server has been essentially built upon
Here are some of my thoughts on this:
1. The current version of the SDS entity design is based on a free-form schema-less model unlike the rigid schema based approach which most RDBMS such as SQL Server, Oracle work on. SDS builds on an Entity definition model wherein the data object constructs gets abstracted to a much higher level. The approach makes the process of low-level object creation such as tables, constraints, relations etc… a job of the SDS layer. As far as the End user is concerned he/she would only be concerned about the Entity definition, this will include attributes along with the data types of those attributes. Though relationships are not supported in the current version of SDS, which the SDS team intents to provide in some future version .And this should not be difficult, they can be inferred easily from the entity object associations which could translate to a low-level parent key- foreign key relationships in the RDBMS parlance
2. The SDS team also plans to have the schema-less flexible entity model be supported by the ADO.NET data services. ADO.NET data service currently supports only standard RDBMS databases. The challenge being to adopt the fixed data objects definitions to support flexible entity definitions within the ADO.NET Entity data framework. As application developers it is time for us to get out of the T-SQL mould and start thinking EDM /LINQ!
3. Additionally data stored on SDS are queried using REST based URI's using LINQ. As this is also the model used for querying entities on the .Net platform. The SDS team could've alternatively adopted a T-SQL model to query the cloud data service, but that may not lend itself efficient to an entity based data access model.
This is also what makes me believe that EDM would be dominating the MS data platform strategy in the years to come which will unify all data access strategies on the .NET platform.
It does not mean RDBMS is going to be done away with. I don’t think that is the case. In fact the SDS instance natively runs on SQL Server 2008 engine which is an RDBMS. It simply means that MS has abstracted most of the low-level db design aspects from the developer and would want them to focus on the domain/functional aspects of their application.
As per Soumitra Sengupta , Product Manager SQL Server, has this to say
"Over time, … as we learn what it takes to run a 24x7x365 service (nobody we know of is running a data service using a commercial database system at this scale and cost point) like SDS, I can assure you we will start to expose capabilities of the underlying engine. How quickly and how much will depend on our ability to provide you, our customers with the quality of service you need to trust your business to SDS."
So we can hope to see some of those SQL Server features being supported on SDS as well.
http://blogs.msdn.com/ssds/archive/2008/06/27/8660471.aspx
