> > And here is a list of caveats for table storage: > Depending which side of the mirror you're looking through, many of your caveats may be considered blessings, especially the "no enforced schema". The absence of the features you listed is what makes the ATS API so mercifully simple and useful in *certain scenarios*. Pick the right tool for the job.
As a technical FYI aside: Over the last few weekends I converted a SQL Db with 20 tables ranging from a dozen to 60000 rows into Azure Tables. Almost all of the work was done by T4 template generated code. I put the schema of the tables and their joins into an Excel sheet and the T4 templates read it to generate all the CRUD classes. I effectively wrote a weird mutated EF for Azure tables (maybe there could be market for that?!). The generated code even simulates joins so you can "deep load" an entity if you want. It was just a technical exercise, but it's actually working and performing so well that I think I'm going to drop the original SQL DB. I would never have dared try that experiment on an app database requiring the concurrency and high-performance that RDBs deliver. *GK*
