不适合这个问题
使用Azure表存储，您只有固定的分区键，rownum。他们根据操作的大小和次数收费。
使用WPF客户端和SQL数据库创建一个局域网文档管理应用程序
把它放到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标识符到客户端。
我查看了Table Storage，但是如果我有100个客户每天进行100次搜索(有些客户确实如此)，并且返回了100,000,000次，那么交易成本加起来(超过700美元)并且Table Storage插入相对较慢。数据库只要15美元。
我可以将结果存储在SQL表
中userID (smallint)， rowNum (int)， docIdentifier (int)
userID, rowNum
上填充因子为50的聚集索引我的问题是，有4,000,000个文档和1,000个登录，仅在该表上就可以占用16 GB
我正在考虑一次向客户端发送100,000个int。
有更好的设计吗?
使用Azure的好处之一是您有多种存储数据的选择。从Azure表，文档数据库，一直到SQL数据库和SQL DW。每个服务都有很好的文档，描述了它们在哪些方面是不同的。
因为你有很多选择，你可能想要在Azure中选择最便宜的存储选项。那是桌子。然而，正如您正确指出的那样，最便宜的并不总是最容易搜索的，而这通常是SQL的优势所在。从SQL中搜索/选择数据通常更容易。
所以这是存储成本，数据吞吐量和易于访问/编程之间的权衡。
我会说Azure表存储是你最便宜的解决方案。关键是，你到底会给用户什么回报?每次100条记录的次数为100.000，我不确定您的用户是否会浏览每个页面。也许你应该考虑另一种报告信息的方式。