与许多开发人员一样，我正在寻找一种将现有应用程序集成到 SQL Azure 联合的方法，而替换身份列（我的表的主键）是一个大问题。
由于许多原因，我不想将 GUID 用作我的主键（请不要打开关于 GUID 的辩论，这不是我的问题：我只是不想要 GUID，句号）。
因此，我需要构建一个密钥提供程序来替换标准 SQL 数据库的“身份”功能。我正在使用实体框架，所以我可以很容易地找到一个Id在插入之前设置值的地方（通过覆盖SaveChanges我的ObjectContext类的方法）。我只需要找到一个“不太复杂”的实现来获取当前的 ID，即“农场就绪”。
我已经阅读了这篇 SO 帖子：“分片数据库（Azure 联合数据库）的 ID 生成”和“来自 MSDN 杂志的在 Windows Azure 中同步多个节点”，但这个解决方案对我来说听起来有点复杂。
我正在考虑为每个 SQL 表创建（自动）一个 azure 队列，其中包含一个预加载的连续整数列表。当我想要一个 Id 值时，我只需要从队列中获取一条消息（它变得不可见并在途中被删除），这给了我当前可用的 Id。
关于“Windows Azure Queues”和“Windows Azure Service Bus Queues”之间的选择，我更喜欢“Windows Azure Queues”，因为Service Bus Queues 的“高”延迟。我不认为 Azure Queues 缺少“订购保证”是个问题。
您如何看待使用 Azure 队列提供 Id 值的想法？你有没有看到任何放弃这个想法的论据？在 SQL Azure 联合数据库中提供整数 id 是否有更好的想法，甚至是好的做法？谢谢。
编辑 ：
阿斯塔科夫建议使用 SnowMaker。我终于完成了SnowMaker的一个分支，以与 Azure 存储库的 v2 完全兼容。
编辑 2
请注意，Azure SQL Federation 将于 2015 年 9 月停用，包括 Web 层和业务层，如此处所述。但是这个问题对于自定义分片解决方案仍然有效。