如果这是重复的，我提前道歉，我不确定我应该搜索什么。
最近，我在第 9 频道观看了这个关于 SQL Azure 中的数据库联合的漂亮视频。起初，我对 SQL Azure 联合不支持标识列这一事实感到惊讶，但这是有道理的。如果表在 2 个（或更多）数据库之间拆分，并且它们无法共享其标识增量值，则最终可能会有 2 个（或更多）个实体共享相同的主键。
该视频轻描淡写地谈到了如何处理这个问题，提到使用 Guid 之类的东西来表示 PK，而不是基于整数的标识列。我知道至少 MSSQL 默认情况下会在 PK 上创建一个聚集索引，并且在 Guid（或唯一标识符）类型上有一个聚集索引是不好的。我绝不是关系专家，但我也相信，与基于 PK 的查找的基于整数的类型相比，Guid 的性能有所下降。
所以这让我想知道，对于水平联合数据库来说，基于整数的 PK 模式会是什么样子？当我编写老式的EJB时，我们需要为主键生成一个整数，我们必须有一个单独的序列查找表来替换rdbms标识/自动增量功能。我记得这是痛苦的，就像当时EJB的许多其他事情一样。
在水平联合数据库表中分配主键的普遍接受模式（如果有）是什么？鉴于我目前的知识，我会因为性能下降而远离 Guid，并且由于开发成本和增加的复杂性（主要是开发成本），我会远离顺序查找索引。我应该倾向于什么？
这样的东西可能很有用，具体取决于应用程序的性质
http://blog.tatham.oddie.com.au/2011/07/14/released-snowmaker-a-unique-id-generator-for-azure-or-any-other-cloud-hosting-environment/