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