这是一个非常主题的话题， blobs vs tables vs SQL ，尽管到目前为止我读过的所有内容仍然无法找到适当的推理原因。
我们有一个多租户SaaS网络应用程序，我们即将迁移到Azure。我们使用SQL Server 2008数据库。我们存储属于文档的文档和日志信息。有点像Dropbox。
论坛声明，在考虑“大型”对象时，最好使用Azure表。我们通常每个用户存储数百个文档，文档大小从5kb到30mb不等，绝大多数都在1MB左右？
有什么基本规则何时去Blob，Tables，Sql？我已经知道我不应该将文档存储在SQL中，因为它太贵了。但是什么时候将文件存储在Blob中变得“有益”，何时我会更好地使用表格？是否有某种公式如下：
if (objects * MB/object * objectrequested > y) then blobs, else tables
答案 0 :(得分：20)
我认为Igorek解决了您对SQL Azure的担忧。不过，你似乎仍然对Tables vs Blobs有疑问。
在你使用Table存储的情况下会很烦人。 ATS中的每个属性/列最多可以是64KB，因此您必须将文档拆分为多个属性，然后重新组合它们。每个实体还有4MB的限制，这将是一个问题。 Blob存储没有这些限制。
如果您的小实体具有许多需要单独存储和查询的属性，我倾向于使用Azure表存储。因此它适用于存储对象或具有大量元数据的小文档。
对于没有大量元数据的事物，Blob存储更有效。这对于可能作为文件系统上的文件运行良好的事情是有益的。
答案 1 :(得分：9)
我会将文档本身存储在Azure Blob存储（不是表存储）中。除了在SQL Azure数据库中存储文档相当昂贵之外，每个meg（或更少，取决于卷）收取一分钱，因此SQL数据库通常不是文档的好地方。 SQL是一种关系数据库，它提供了执行查询，连接等功能的好处。在SQL数据库中存储大型文档或图像通常没有任何好处，特别是当存在高度可扩展的中央存储系统时，存储起来非常便宜/访问。
现在，如果您需要通过文档本身进行搜索，我会使用像Lucene.NET这样的东西为基于文档的存储库提供搜索功能。
HTH