Microsoft® SQL Data Services offers a variety of web-facing relational database features. This feature representation is a relatively high-level look at the available features; for in-depth feature information, please visit the SQL Services Dev Center.
Basic Components of Data Model
The SDS runtime provides a simple, hierarchy-based data model that consists of three layers: authorities, containers, and entities. An authority is a collection of containers, and a container is a collection of entities. This is known as the ACE model.
- Authority – Unit of Geo-Location, Unit of billing, Collection of containers
- Container – Unit of consistency, Scope of query, Collection of entities
- Entity – Unit of data for operations, collection of properties
System Properties
SDS System Properties are common to all entities. These properties are not updateable and contain information such as ID, Version, and user defined properties for Authorities and Containers which meta data on the data contained within.
Open Types
Entities with no enforced schema.
Blob Support
SDS provides rich support for Binary Large Objects or Blob data. BLOB support enables you to store videos, images, and other files as binary-encoded data, making SDS a feasible data platform for photo or video clip libraries, music players, document stores, and any number of other innovative applications.
Data Types
SDS provides the necessary data types needed in a data platform. These include types such as String, Date/Time, Boolean, Numeric and Binary.
Primitive Operations
SDS supports CRUD (Create, Read, Update, Delete) operations as well as queries on large amounts of data.
Conditional Update/Delete
SDS provides support for conditionally updating and deleting data. On the REST interface this is accomplished through the use of industry standard HTTP headers such as If-Match and If-None-Match. On the SOAP interface there is a similar mechanism through the use of a custom object.
Transactional Consistency
SDS supports an immediate consistency model which means each operation performed will be committed across all SDS nodes for redundancy.
Optimistic Concurrency
Concurrency control is currently handled in the application through the use of the conditional update semantics this helps provide the same level of consistency as a traditional database.
Data Versioning
SDS assigns a unique timestamp to an entity on each operation to ensure track history.
Supported Web Interface (i.e. REST or SOAP)
SDS is accessed via web services calls to either its SOAP or REST interface. By providing feature symmetry across both interfaces, SDS users are offered a robust development experience regardless of development platform.
Query Scope
In SDS, each query is scoped, or issued against, a specific layer in the ACE (Authority, Container, Entity) model. This provides a consistent development experience regardless of what level of the hierarchy developers are programming against
Query Language
SDS queries are constructed in a variant of the LINQ language syntax called SLINQ.
Query Operation
SDS offers the standard intrinsic operations expected from a database including support for Joins, Top and OrderBy.
Boolean Operation
Compound query predicates are supported through the use of Boolean operators (AND, OR, NOT). Additional flexibility can be found by using parentheses along with the Boolean operators to further fine tune queries.
Comparison Operation
SDS supports common comparison operators including equality, inequality, greater than and less than (<, >, <=, >=, !=, ==)
Authentication
SDS supports both a basic authentication model (http over https) and also provides support for the Microsoft .Net Services offerings.
Authorization
In the current version of SDS, each authority can only have a single owner and that owner has full access to all the data contained within.
Permission model
In the current version of SDS, each authority can only have a single owner and that owner has full access to all the data contained within.
X.509 Certificate
When used with .NET Services’ Access Management Service, authentication can be delegated to own permission store through the use of X.509 certificates.
Windows CardSpace
SDS supports authentication via Windows CardSpace credential. This feature is only available when using the Access Management Service.
Windows Live ID
The Windows Live ID support is for Authentication adds support to authenticate via Windows Live Id. This integration will allow access to the service.
Number of Authorities per account
SDS supports an unlimited number of Authorities per account (both single and multitenant).
Maximum Number of Containers per Authority
Currently, Authorities may contain a maximum of 1000 containers which, thus far, has proven to be sufficient support.
Maximum Size per Container
Each Container may hold a maximum of 1 gigabyte of Blob entities and 100 megabytes of Flexible entities. These limits are imposed during the SDS open beta and may be re-evaluated in the future. It is important to note that while SDS has no theoretical data storage limit, these quotas have been put in place to enable backup and restore that doesn’t affect system performance and also features such as geo-replication and other disaster recovery mechanisms.
Maximum size per Flexible entity
Each flexible entity can be a maximum of 2 megabytes
Maximum size per Blob entity
Each Blob entity may be a maximum of 100 megabytes.
