我们有一个相当大的解决方案，它使用 FileStream 在 Sql Server 2008 中存储大量图像、视频、文档。我们已经开始迁移到使用 Windows azure blob 存储来利用地理复制，这意味着将 varbinary(max) 列更改为相对 url，我们将附加指向我们的存储帐户的自定义子域。
这一切都很好，我们很高兴进行测试，但是我们目前使用 varbinary 数据存储 Filename、extension 和 contentType。
我的问题是，如果我们只是去一个相对的 url，如果需要的话，它会有文件扩展名，我们需要存储这些额外的数据吗？我们正在办公室辩论，共识似乎是保持简单，只存储 URL。
大多数人在这种情况下会做什么？存储这些额外数据的用途/好处是什么？
非常感谢您对此的想法，外部意见可能会解决这个问题。
我倾向于将任何关于我存储在 Azure 中的文件的元数据（我认为可能有用的）保存在 SQL 和 URI 中。
什么是“有用的”？
这实际上取决于您的情况。例如，我发现（从操作/监控的角度来看）根据 URI 存储文件大小很有用，这样我就可以轻松快速地查看文件存储使用情况。我还存储文件扩展名/内容类型。基本上，我尝试在本地保存任何可以节省我的元数据，否则我不得不实际离开并与 Azure 交谈，a) 以提高速度/性能和 b) 最大限度地减少 API 上的命中数（从而降低成本 - 只是真的如果你做了很多点击）
所以我知道，对于任何可能需要详细文件可用的报告需求/UI，我可以生成一些有用的元数据，而不必去 Azure 附近的任何地方。然后只有在我确实需要获取文件时才真正接触 Azure。
您可能会发现有两件事很有用：每个 blob 都有一个“内容类型”系统属性，可以在上传 blob 时设置（您也可以稍后更改它）。另一件事是，您也可以使用 blob 以键值对的形式指定自定义元数据。但是元数据不可搜索。因此，如果您想根据一些自定义属性搜索 blob，最好将它们存储在 blob（SQL 服务器）之外。元数据的另一件事是它的最大大小。如果我没记错的话，有 8 KB 的限制。