One of the cool, and frustrating things, about dealing with cutting edge technology is how stuff changes so fast. Some of my links and bookmarks aren’t working until I start hacking the URL to find what it is I thought I had.
I’m going to make a minor change in plans and break my posts into two sub-categories; Hands-on learning and my experiences, and my interpretation of the online materials.
What are SQL Data Services (SDS)?
- Providing data and data access as a service.
- Highly scalable without having to manage the physical infrastructure.
- The capacity of the system is only limited by the amount of data you are putting into it.
- Supports REST and SOAP
The SDS data model uses concepts of authorities, containers and entities. The data model has a flexible schema, which make it very easy to create your data structures.
The “ACE” Model.
A is for Authority:
the authority is the topmost level of the hierarchy and is represented by a DNS name. For instance, in the URL, duringlunch.data.database.windows.net, “duringlunch” is the authority, with everything after being the reference to the service. What is cool about this is the authority maps to a specific data center. In other words an authority is a unit of geo-location.
C is for Container
Authorities contain containers. Each of these containers have a unique id associated to them, and store the data used in the application. As authorities are geo-located, so are the containers within them. Containers cannot be in a different geo-location than the authority holding them. Container can have either homogeneous or heterogeneous data.
E is for Entity
Entities are the actual bits of data stored in the container. Each entity stores any number of user-defined properties with the corresponding values. Entities can be retrieved, added, updated, deleted. However partial updates are not supported. When updating, the entire entity is replace in the container.
Homogeneous or Heterogeneous – everyone has a right to what they want.
As mentioned before containers can hold either homogeneous or heterogeneous data. Similar to a table in a database, homogeneous are entities which are all of the same kind. For instance a “Books” container stores all types of “book” entities. A heterogeneous container is more like an entire database with entities of all kinds. An example of a heterogeneous container would hold “book”, “office supply”, “furniture” entities.
Which is better? Hard to say, it depends on what your application needs. For the highly structured applications, use homogeneous containers. Heterogeneous containers allow for querying across all the entities stored in the parent container.
Flexible Entities
The key concept of SDS is the Flexible Entity. Flexible entities are XML fragments with one element per property value. Each property has a name and a value, with the value restricted to a simple scalar type of string, binary, boolean, decimal, or datetime. Each flexible entity has fixed metadata properties of “Id”, “Version”, and “Kind”, with “Version” acting as a timestamp. With each update, a new version is automatically assigned. “Kind” is user-defined, identifying the entity type. Entities can have additional user-defined flexible properties with any name and scalar type of the types listed above.
More soon,
James