azure - Azure SQL 数据库中的主键

标签 azure domain-driven-design primary-key azure-sql-database cqrs

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

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

  1. 如果您使用本地 SQL Server 计算机,则顺序 guid 会很好 - 生成的顺序 guid 将始终是唯一的。然而,在 Azure 上,情况不再如此。正如 this thread 中所讨论的,甚至不再支持;生成它们也是一个坏主意,因为它会成为单点故障,并且无法保证跨服务器的唯一性。我想顺序指南在 Azure 上没有意义,所以我应该坚持使用常规指南。这是正确的吗?

  2. Guid 类型的列不适合聚类。但是this article指出 Azure 上并非如此,并且 this one建议相反!我应该相信哪一个?我是否应该将我的主键设置为 guid 并将其保留为集群(因为它是主键的默认值)?或者我不应该将其聚类并选择另一列进行聚类?

感谢您的见解!

最佳答案

the sequential guids that are generated will always be unique. However, on Azure, this is not the case anymore.

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

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

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

有可能,从 *SELECT * FROM TABLE WHERE Id = "的角度来看,返回单个实例是没问题的。

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

关于azure - Azure SQL 数据库中的主键,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/18172891/

相关文章:

mysql - 使用 PRIMARY KEY 会降低 innodb 文件大小吗?

oracle - 如何在PL/SQL中合并两个类似的数据库架构?

java - 如何使用 JDO(datanucleus 和 appengine)存储键值对

azure - 如何在不明确指定版本的情况下将 Azure 角色切换到 Windows Server 2008 R2?

Azure 上的 Node.js 远程调试

node.js - 从 Azure 函数上传文件到 Azure 存储 - Nodejs

c# - 如何控制 IEnumerable 的更新

domain-driven-design - 事件源系统中的流聚合关系

azure - 创建资源时触发 Azure Function

domain-driven-design - Domen 驱动的架构和用户拼写错误/错误