无法找到最适合此问题的方法
使用 Azure 表存储，您只需拥有固定的分区键 rownum。他们根据操作的规模和数量收费。
拥有一个带有 WPF 客户端和 SQL 数据库的 LAN 文档管理应用程序
将其带到 Azure，我希望最大限度地降低成本
大多数应用程序大约有 100,000 个文档
但高端可能有 400 万个文档
大多数 SQL 搜索都很便宜(0.1 秒)，但有些可能很昂贵(例如 60 秒)。
在 LAN 版本上，我所做的是返回 100 的详细信息，但返回 10,000 的原始标识符。因此，当客户端需要下一页的详细信息时，它只需发回下 100 个页面的标识符 (int) 以及对详细信息的非常便宜的查询。我不保留前一页的详细信息，它会使用太多的客户端内存。当达到 10,000 时，我会搜索下一个 10,000。
在 Azure 环境中是否有任何理由进行更改？我正在为带宽付费，但 int 非常小。我还支付 SQL CPU 和 IO 费用。如果有的话，我正在考虑向客户端发送 100,000 个标识符。
我查看了表存储，但如果我有 100 个客户端每天执行 100 次搜索(有些确实这样做)并且返回 100,000,000 个，则交易成本会增加(超过 700 美元)，并且表存储插入相对较慢。该数据库仅需 15 美元。
我可以将结果存储在 SQL 表中
userID (smallint), rowNum (int), docIdentifier (int)
userID、rowNum 上填充因子为 50 的聚集索引
我的问题是，有 4,000,000 个文档，1,000 次登录，仅该表就占用 16 GB 空间
我正在考虑一次向客户端发送 100,000 个 int。
有更好的设计吗？
最佳答案
使用 Azure 的好处之一是您有多种存储数据的选择。从 Azure 表、文档 DB，一直到 SQL DB 和 SQL DW。每项服务都有出色的文档，描述了它们在最擅长的方面有何不同。
由于您有选择，因此您可能希望选择 Azure 中最便宜的存储选项。那将是 table 。然而，正如您所指出的，最便宜的并不总是最容易搜索的，而这通常是 SQL 的优势所在。从 SQL 中搜索/选择数据通常更容易。
因此，这是存储成本、数据吞吐量和易于访问/编程之间的权衡。
关于.net - SQL Azure 分页优化，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/39689130/