Question

使用它作为数据存储ID（SQL Server）是否可靠？

我会使用guid，但我更喜欢数值。

Answer 1

guid更有可能代表唯一的记录而不是numeric value。

同时：

GUID确保全球唯一性
GUID可以跨数据库移动很好地
GUID会减少联接次数需要

请参阅：Guid Or Int Primary Key?

Answer 2

使用它作为数据存储ID（SQL Server）是否可靠？

没有。 GUID是128位，但哈希码是32位。因此，必然会发生碰撞。你可能不会遇到一个，但你不能保证永远不会遇到一个。

您对可靠性的要求是您永远不会遇到碰撞的保证。如果您坚持使用Guid.NewGuid().GetHashCode()，则需要添加逻辑来检测冲突。 GUID确实有优点（和缺点），但如果没有其他信息，我建议使用自动递增int列。特别是当你说你想要一个数字列时，我倾向于使用IDENTITY。

Answer 3

真正的GUID设计为唯一的。当你将它减少为int（通过GetHashCode）时，它的唯一性降低了。

使用GUID（唯一性）有一个很好的理由，此代码会删除该GUID功能。

Answer 4

如果您想要数值，请使用IDENTITY列。如果您想要GUID，请使用uniqueidentifier。就这么简单。

不要试图混合搭配。不要散列GUID以获取数值。这将为您提供GUID列的所有缺点（更大的数据/索引，页面拆分），同时激发大部分优势（实际的唯一性，复制支持）。此外，您不会获得顺序数字ID给您带来的任何好处，例如时间排序和索引性能。

Answer 5

我想说只需使用GUID作为列上的值。没问题。

Answer 6

Dim bom As New Dictionary(Of Long, Boolean)

Sub pageload() Handles Me.Load
    For i = 0 To 500
        Dim act As New Action(AddressOf collisionfind)
        act.BeginInvoke(Nothing, Nothing)
    Next
End Sub

Sub collisionfind()
    For index = 1 To 50000000
        Dim INTGUID = Guid.NewGuid.GetHashCode / 2 * Guid.NewGuid.GetHashCode / 2
        bom.Add(INTGUID, Nothing)
    Next
End Sub

嗯，我想毕竟它几乎一样好。

没有碰撞：D。

50000000 500个线程上的循环非常繁重。这对我来说已经足够了。

Answer 7

这是一种常见的方法，我会为这条路线直接指出一个很好的理由。您可以在点击DB之前生成GUID，您可以异步执行说插入，并且您将提前知道ID将是什么。

确保您的主键数据类型为UNIQUEIDENTIFIER类型，并且您已完成设置。

Guid.NewGuid（）。用于DB的GetHashCode（）

7 个答案: