我已经开始研究我的第一个Azure应用程序了，而且我在学习的过程中学到了很多东西。我最近发现的一个功能是SQL Azure中的Federations，本质上是SQL Azure分片实现，因此我们可以横向扩展。
我的项目开始使用SQL Server，并且已经在很大程度上按用户配置文件进行分组，因此我认为联邦最有意义。我创建了联合，包括所有带有一个障碍的子表 - 不支持Identity。我明白为什么它不受支持，我不确定什么是最好的替代它。这似乎是其他人必须解决的一个巨大问题，但我找不到多少。
我可以使用UniqueIdentifier，但我读到这可能是一个痛苦的分裂。我也不太清楚使用GUID作为联邦表的主键可能遇到的其他性能问题。
我在Entity Framework中使用它，但尚未达到使该联盟友好的程度。据我所知，在编写LINQ查询之前执行某些代码来选择联邦并不复杂，但是当我到达它时，我将跨过那个桥。
目前，我不知道如何最好地将项添加到我的联合中，因为没有很好的解决方案来生成身份。
非常感谢任何建议。
答案 0 :(得分：2)
我在使用SQL Azure Federation时使用GUID，它几乎是数据分片时的最佳选择。假设您在许多联合成员中使用Identity，这将导致您的主值重复。当您需要合并数据或存档时，如何处理这些记录。
人们认为GUID在数据插入时性能较低，特别是如果我们将其用作聚簇索引。但我从未遇到过这个问题。或者我应该说，我们可以做很多调整，而不是这个。
答案 1 :(得分：0)
所以我无法谈论EF问题。但我无法评论使用Uniqueidentifier作为您的密钥类型的想法。在我看来，这是最好的选择。 UniqueIdentifier实际上很容易拆分......人们认为很难忘记UniqueIdentifier是什么。我们都知道和喜欢的GUID是128位整数的十六进制表示。这意味着我们可以使用标准的Integer操作，因此它实际上与您熟悉和喜爱的Int（自动编号）一样容易使用。
虽然它不是专门针对SQL Azure联盟（它是关于Windows Azure存储）的，但我的这篇博文中使用GUID类型进行分片应该可以为您提供所需的一切。
http://www.syringe.net.nz/CommentView,guid,cebe3e19-85e6-4d5b-bc24-afb6f66aaeb1.aspx