5

我正在开发一个使用 CQRS 和 DDD 原则的分布式系统。基于此，我决定我的实体的主键应该是由我的域（而不是数据库）生成的 guid。

我一直在阅读有关 guid 作为主键的信息。但是，如果应用于 Azure SQL 数据库，某些最佳实践似乎不再有效。

  1. 如果您使用本地 SQL 服务器计算机，则顺序 guid 非常好 - 生成的顺序 guid 将始终是唯一的。但是，在 Azure 上，情况不再如此。正如该线程中所讨论的，它甚至不再受支持；并且生成它们也是一个坏主意，因为它会成为单点故障，并且不再保证跨服务器的唯一性。我猜顺序 guid 在 Azure 上没有意义，所以我应该坚持使用常规 guid。这个对吗？

  2. Guid 类型的列不适合进行聚类。但是这篇文章指出，Azure 上的情况并非如此，而这篇文章则相反！我应该相信哪一个？我是否应该将我的主键设为 guid 并使其保持集群状态（因为它是主键的默认设置）；还是我不应该将其聚类并选择另一列进行聚类？

感谢您的任何见解！

4

2 回答 2

1

生成的顺序 guid 将始终是唯一的。但是，在 Azure 上，情况不再如此。

在这里查看这篇文章的底部 - http://blogs.msdn.com/b/sqlazure/archive/2010/05/05/10007304.aspx

Guid（依赖于NEWID()）的问题是它们将随机分布，这在向它们应用聚集索引时会出现性能问题。

我建议您使用 GUID 作为主键。然后从该列中删除默认聚集索引。将聚集索引应用于表上的其他字段（即创建日期），以便记录在创建时按顺序/连续索引。然后将非聚集索引应用于您的 PK Guid 列。

很有可能，从 *SELECT * FROM TABLE WHERE Id = " 的角度来看，返回单个实例会很好。

同样，如果您要返回列表或记录范围以在列表中显示，如果您按 CreatedDate 指定默认顺序，则您的聚集索引将适用于此

于 2013-08-12T11:24:59.313 回答
1

考虑以下

  1. Sql Azure 需要聚集索引来执行复制。请注意，索引不必是唯一的。http://blogs.msdn.com/b/sqlazure/archive/2010/05/12/10011257.aspx

  2. 聚簇索引的优点是对索引的范围查询以最少的搜索次数得到最佳执行。

  3. 聚簇索引的缺点是，如果数据乱序添加，可能会发生分页，插入速度可能会相对较慢。

参考以上，我建议以下

  1. 如果您有一个真正的键范围，您需要查询，例如日期、序号等
    1. 为该键创建一个（唯一/非唯一）聚集索引。
    2. 使用域生成的 GUID 创建一个额外的唯一索引。
  2. 如果不存在真正的键范围，只需使用域生成的 GUID 创建聚集唯一索引。（添加虚假的不需要的聚集索引的开销更多的是障碍而不是帮助。）
于 2014-01-17T02:19:12.620 回答