身份列作为主键

发布于 2024-08-13 22:08:00 字数 88 浏览 2 评论 0原文

您能否发表意见,将身份列作为主键是否是一个好的做法? 对于 ORM 工具,表上有标识列会有所帮助。但还有其他副作用,例如意外重复插入。

谢谢 纳恩

Could you please opine if having identity column as primary key is a good practise?
For ORM tools, having identity column on tables helps. But there are other side effects such as accidental duplicate insertion.

Thanks
Nayn

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

瑾兮 2024-08-20 22:08:00

是的,对于 SQL Server 来说,使用 INT(或 BIGINT)IDENTITY 是非常好的做法。

SQL Server 使用主键作为其默认的聚簇键,并且聚簇键应始终具有以下属性:

  • 静态
  • 唯一
  • 不断增加的

INT IDENTITY 完全符合要求!

有关更多背景信息,尤其是为什么将 GUID 作为主要(以及集群键)是一个想法的信息,请参阅 Kimberly Tripp 的精彩帖子

  • : sqlskills.com/BLOGS/KIMBERLY/post/GUIDs-as-PRIMARY-KEYs-andor-the-clustering-key.aspx" rel="nofollow noreferrer">GUID 作为主键和/或集群键
  • < a href="http://sqlskills.com/BLOGS/KIMBERLY/post/The-Clustered-Index-Debate-Continues.aspx" rel="nofollow noreferrer">聚集索引争论仍在继续...
  • < a href="http://www.sqlskills.com/BLOGS/KIMBERLY/post/Ever-increasing-clustering-key-the-Clustered-Index-Debateagain!.aspx" rel="nofollow noreferrer">不断增加的集群key - 聚集索引争论......再次!

如果您有理由使用 GUID 作为主键(例如复制),那么请务必确保有一个 INT IDENTITY 作为您在这些表上的集群键

马克

Yes, using a INT (or BIGINT) IDENTITY is very good practice for SQL Server.

SQL Server uses the primary key as its default clustering key, and the clustering key should always have these properties:

  • narrow
  • static
  • unique
  • ever-increasing

INT IDENTITY fits the bill perfectly!

For more background info, and especially some info why a GUID as your primary (and thus clustering key) is a bad idea, see Kimberly Tripp's excellent posts:

If you have reasons to use a GUID as primary key (e.g. replication), then by all means make sure to have a INT IDENTITY as your clustering key on those tables!

Marc

剩一世无双 2024-08-20 22:08:00

在没有复制或大量数据合并的环境中,IDENTITY 密钥是服务器端生成密钥的良好实践。它们的实现方式不允许同一个表中有重复项,所以不用担心。它们还具有最大程度地减少没有大量 DELETE 的表中的碎片的优点。

GUID 是通常的替代方案。它们的优点是您可以在 Web 层创建它们,而不需要数据库往返。但是,它们比 IDENTITIES 大,并且可能导致极端的表碎片。由于它们是(半)随机的,因此插入分布在整个表中,而不是集中在最后的一页中。

IDENTITY keys are a good practice for server-side generated keys, in environments where you don't have replication or heavy data merging. The way they're implemented, they don't allow duplicates in the same table, so don't worry about that. They also have the advantage of minimizing fragmentation in tables that don't have lots of DELETEs.

GUIDs are the usual alternative. They have the advantage that you can create them at the web tier, without requiring a DB round-trip. However, they're larger than IDENTITIES, and they can cause extreme table fragmentation. Since they're (semi) random, inserts are spread through the entire table, rather than being focused in one page at the end.

阳光下慵懒的猫 2024-08-20 22:08:00

我使用 Guid 是因为它在处理分布式应用程序时确实很有帮助。特别是当所有分布式实例也需要创建新数据时。

尽管如此,在简单的情况下,我没有看到自动增量整数主键有任何问题。实际上我更喜欢它们,因为直接使用 SQL 查询更容易,因为它更容易记住。

I use a Guid because it really helps when I am dealing with distributed applications. Especially when all the distributed instances also need to create new data.

Nevertheless, I don't see any problems with autoincrement integer primary keys in simple situations. I would prefer them actually because it is easier to work directly with SQL queries because it is easier to remember.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文