Oh, Table Storage ...

I'm having a ton of fun with Azure, but the one "version 1.x" feature that bugs me is the immaturity of table storage.

The fundamental ideas behind table storage are great - hi speed, low cost, non relational data. The issues I have are with the details of the implementation.

First off there's the supported structures. Why to we have to use flat objects? Why limit things to, basically,  a property dictionary, when  the semantics support graph serialization? Maybe constraints are good, but I find this limits the transparency of working with Table storage.

My next issue, while it's all well and good using 'similar' semantics to other technologies like Data Services, LINQ and Entity Framework, it kinda defeats the DRY principle in that it's not the same. Why was table storage not provided as a provider for Entity framework, as well as an abstraction over Data Services?

Lastly that brings me to Dev storage. Look, having local easy to configure tools is great, but there are known issues that just hurt the experience Oliver Jones covers some details here: http://deeperdesign.wordpress.com/2010/03/10/azure-table-storage-what-a-pain-in-the-ass/

My thought is, why mess around "faking" table storage over express anyway, when the whole point is to avoid SQL Server?

I figure the semantic and dev fabric issues could actually be solved quite easily, together - release a 'production' ready local version of table storage. This would help unified architecture and the dev experience.