我正在编写一个"概念验证"应用程序，以调查移动定制ASP的可能性。. NET电子商务系统在整个应用程序的必要重写期间迁移到Windows Azure。
我想看看使用Azure表存储作为SQL Azure的替代方案，因为随着应用程序的进一步成熟，存储的实体可能会随着时间的推移改变它们的模式(属性)，我不需要无休止地更改数据库模式。此外，我们可以在应用程序代码中构建参照完整性——因此考虑使用Azure表存储是一个很好的理由。
目前我能看到的唯一潜在问题是，我们做了少量简单的报告，即两个日期之间的销售额，特定产品的销售数量等。我知道表存储不支持聚合类型函数，我相信我们可以实现我们想要的巧妙使用分区，多个实体类型来存储相同数据的子集和可能的预聚合，但我不是100%确定如何去做。
有没有人知道任何关于Azure表存储设计原则的深入文档，以便我们正确有效地使用表，PartitionKeys和实体设计等?
周围有一些简单的文档，目前可用的书籍往往不太深入地讨论这个主题。
仅供参考-该电子商务网站拥有约25,000个客户，每年约有100,000个订单。
你看到这篇文章了吗?http://blogs.msdn.com/b/windowsazurestorage/archive/2010/11/06/how-to-get-most-out-of-windows-azure-tables.aspx
非常全面地覆盖了表
我认为将你的应用移植到Table Storage有三个潜在的问题。
- 缺少报告——包括聚合函数——你已经确定了
- 事务支持的有限可用性-每年有100,000个订单，我想你最终会错过这种支持。
- 一些成本问题——每百万次操作1美元只是一个很小的成本，但如果你有很多页面浏览量，你就需要考虑到这一点。
老实说，我认为混合方法-也许EF或NH到SQL Azure的关键数据，与大对象存储在表/Blob?
我的意见够多了!对于"in depth":- 试试存储团队的博客http://blogs.msdn.com/b/windowsazurestorage/-我发现这个非常好
- 试试Jai Haridas的PDC会议(没有发现链接-但我确定它仍然在那里)
- 试试Eric的书里的文章- http://geekswithblogs.net/iupdateable/archive/2010/06/23/free-96-page-book---windows-azure-platform-articles-from.aspx
有一些非常好的基于建议的最佳实践- http://azurescope.cloudapp.net/-但这有点以性能为导向
如果您已经开始考虑Azure存储(如表)，那么看看市场上的其他NOSQL产品(特别是文档数据库)不会有什么坏处。这将使您深入了解NOSQL空间以及如何围绕此类存储设计解决方案。您也可以考虑采用SQL DB + NOSQL的混合解决方案。系统的某些部分可能非常适合Azure表存储模型。NOSQL解决方案(如Azure表)有它们自己的挑战，例如
- 数据的架构更改。查看此处和此处
- 事务支持
- 酸约束。在这里检查
我所看到的所有表设计论文几乎都是专门关注可伸缩性和搜索性能的主题。我没有看到任何与报告或BI的设计考虑相关的内容。
现在，azure表可以通过rest api和azure SDK访问。根据您需要的报告，您可能能够以最小的努力提取所需的信息。如果您的报告需求非常复杂，那么SQL azure与Windows azure SQL报告服务可能是一个更好的选择?