In the last post we started looking at table storage and denormalization, but we didnâ€™t actually use table storage at all. The first thing to know is that your data objects need to extend
This base class is required to provide the two key properties: partition and row key. These two keys are important forÂ identifyingÂ each record in the table. The row key Â provides a unique value within the partition. The partition key provides a hint to the table storage about where the table data should be stored. All entries which share a partition key will be on the same node where as different partition keys within the table may be stored on different nodes. As you might expect this provides for someÂ interestingÂ query optimizations.
If you have a large amount of data or frequent queries you may wish to use multiple partition keys to allow for loadÂ balancingÂ queries. If youâ€™re use to just slapping aÂ monotonicallyÂ increasing number in for your ID you might want to rethink that strategy. The combination of knowing the partition key and the row key allows for very fast lookups. If you donâ€™t know the row key then a scan of the entire partition may need to be performed which isÂ relativelyÂ slow. This plays well into our idea of denormalizing. If you commonly need to look up user information using e-mail addresses then you might want to set your partition key to be the e-mail domain and the row key to be the user name. In this way queries are fast and distrubuted. Picking keys is a non-trivial task.
A key does not need to be constructed from a single field either, you might want to build your keys byÂ concatenatingÂ several fields together. A great example might be if you had a set of geocoded points of interest. You could build a row key by joining the latitude and longitude into a single field.
To actually get access to the table storage you just need to use the table client API provided in the latest Azure SDK.
inserting records is simple. I use automapper to map between my domain objects and the table entities.
It is actually the same process for updating an existing record.
A simple retrieve operation looks like
Those are pretty much the basics of table storage. There is also support for a limited set of Linq operations against the table but for the most part they are ill advised because they fail to take full advantage of the key based architecture.