在领域驱动设计中，将 guid 作为身份字段更好吗？
使用 guid 作为标识字段而不是自动递增整数时，是否更容易实现域驱动设计？使用指南，您不必跳转到数据库来获取实际值。
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
使用 guid 作为标识字段而不是自动递增整数时，是否更容易实现域驱动设计？使用指南，您不必跳转到数据库来获取实际值。
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（6）
嗯，GUID 很简单，而且看起来是最合适的。它们对前端程序员很有吸引力，因为他们不必处理数据库。
另一方面，当看到它们在使用时存在的潜在缺点而没有过多考虑数据库问题时，我会尽可能地警告它们。
真正的问题是：在将实体存储到数据库之前，您真的需要知道实体的 ID 吗？真的吗？ 为什么？
如果您最终决定使用 GUID，并且您使用 SQL Server 作为数据库后端（我对其他 RDBMS 的了解不够，无法提出明智的建议），我强烈建议您绝对确保 GUID不被用作表上的集群键。毫无疑问，这会影响你的表现。
如果您确实使用 GUID 作为主键，请确保使用其他内容（对数据库破坏较小的其他列）作为集群键 - INT IDENTITY 将是我的第一选择。
查看 Kimberly Tripp 撰写的这些文章，了解为什么 GUID 作为 SQL Server 数据库中的集群键绝对不是一个好主意 - 在索引和索引性能问题方面，她是终极大师，而且她可以使这些观点比我以前能做得更好：
Marc
Well, GUIDs are easy and look like the best fit. They're tempting to frontend programmers, since they don't have to deal with the database.
On the other hand, when looking at the potential drawbacks they have when used without thinking about database issues too much, I would warn against them as much as possible.
The question really is: do you really need to know the ID of the entity before it's stored in the databsae? REALLY? WHY?
If you do decide to go with GUIDs in the end, and if you're using SQL Server as your database backend (I don't know enough about other RDBMS to make an informed suggestion), I would strongly recommend you make absolutely sure that the GUIDs are not being used as the clustering key on the tables. This will kill your performance - no doubt.
If you do use GUIDs as your primary key, make sure to use something else, some other column that wrecks less havoc on your database, as your clustering key instead - a INT IDENTITY would be my first choice.
Check out these articles by Kimberly Tripp on why a GUID is definitely not a good idea as a clustering key in a SQL Server database - she's the ultimate guru when it comes to indexing and performance issues with indexing and she can makes those points much better than I ever could:
Marc
DDD 的核心原则之一是持久无知。因此，GUID 是为对象提供唯一标识的最简单方法，而无需依赖持久性存储。
注意：如果您担心使用 GUID 的数据库性能，请考虑使用 COMB（特别是针对 SQL Server 索引碎片）
One of the core tenets of DDD is Persistence Ignorance. So yes, GUIDs are the easiest way to provide your objects with unique identity without having to rely on a persistence store.
NB: If you're concerned about database performance using GUIDs, consider using COMBs (specifically for SQL Server index fragmentation)
我推荐Guids，因为你不会对你正在看的东西感到困惑。另外，我知道这经常被当作笑话，但我必须调试系统中发生的一个问题，该系统正在寻找 uint 而不是 guid。这导致共享点中的模板被停用，并且我们无法重新激活它。花了两天时间才发现根本问题是什么。回顾一下 Guid 的情况。
I recommend Guids as there is no confusion as to what it is you are looking at. Also, and I know this gets tossed around as a joke a lot, but I had to debug an issue that happened in the system where it was looking for uint's instead of guids. This caused a template in sharepoint to be deactivated and gave us no way to reactivate it. Took 2 days to discover what the underlying issue was. So to recap go with Guid's.
我认为 GUID 相对于递增整数的唯一优势是身份创建的去中心化。也就是说，递增整数需要原子递增并读取共享值，而 GUID 可以独立创建，几乎不用担心冲突。
至于您的建议，即 GUID 允许人们在不咨询数据库的情况下取消引用实体，我不明白情况是怎样的，因为缺少您的问题中未提及的其他一些信息。您在这里的选择是密钥类型之一，而不是是否使用密钥。如果您手头有一个键，并且该键通过数据库映射到一个值或实体，则需要查阅数据库来取消引用该键。
The only advantage I see to GUIDs over an incrementing integer is decentralization of identity creation. That is, the incrementing integer requires an atomic increment and read of a shared value, while GUIDs can be created independently with little fear of collision.
As for your suggestion that GUIDs allow one to dereference an entity without consulting the database, I don't see how that's the case, absent some other information not mentioned in your question. Your choice here is one of key type, not whether or not to use a key. If you have a key in hand, and the key maps to a value or entity by way of the database, you need to consult the database to dereference the key.
我使用 guid 的原因有两个：
但是，我不一定说这些论点仅适用于领域驱动设计。
I use guid's for two reasons:
However, I would not necessarily say that these arguments are valid only for domain-driven design.
不，绝对不是。 GUID 是不应泄漏到您的域中的实现细节。你需要一个身份值对象，我不关心你如何实现它。
No, definitely not. A GUID is an implementation detail that is not supposed to leak into your domain. You need an identity value object, and I don't care how you implement it.