Sql 基于数据库中跨系统的唯一对象名称创建数字键？

我有一个数据库，它使用唯一的文本键来链接对象。例如，在插入用户时，将使用文本键“{date}-{system}-{user}”插入用户，其中键的每个元素都是字母数字。然后对照查找表检查它是否存在，如果不存在，则将其插入表中并创建一个自动递增整数键。否则，将重复使用相同的整数键

然后，如果插入了该用户的唯一属性，则将匹配该用户的数字键并将其指定为外键。例如，使用用户键“{date}-{system}-{user}”和生成整数键的文档“{date}-{system}-{user-{document}”的唯一文本键插入对此用户唯一的文档

通过这种方式，有一个数字键将这两个条目关联起来，文档有一个唯一的键用于向其附加属性。这些键用于各种查询

当然，问题是，不同系统的键并不相同，这取决于插入元素的方式和时间。因此，我最初的想法是使用哈希作为生成的键，但我认为int和bigint是相当有限的

我不确定SQL server将如何处理外键的长字符串哈希，我已经读到它在性能方面做得不好。否则，我可以只使用创建键本身的文本

假设文本键是唯一的，您将如何确保int、bigint或string（如果可能）键在整个系统中是唯一的？哈希？GUID？如果使用了bigint（63位？）位键，如何处理哈希冲突

---

谢谢！

John，如果可能的话，您可以重新考虑您的密钥体系结构，因为这是为密钥使用GUID的理想情况。这样，您可以为任何系统上的任何用户生成唯一密钥，并且可以99.99999999999……%保证不会发生任何冲突。这也只有16个字节。您可以始终保留您的密钥现有的键结构作为另一列，但可能仅用于其他目的，而不是识别或使记录唯一。我建议，只有当您的应用程序使用此信息执行某些任务时才会出现这种情况，否则，请完全删除它

---

在这种情况下，使用GUID作为键的好处在于它是独立于平台的，也就是说，您可以在Oracle、SQL Server、unix、windows上使用它……

冲突将使这一切变得一团糟-在大多数冲突避免方案中，您会为当前尝试分配的项搜索一个新值。现在想象两个文本hat散列到相同的值，

k1

和

k2

；在一个系统上，它在

k2

之前遇到

k1

（因此

k1

获取未修改的散列值），在另一个系统上，它在

k1

之前遇到

k2

（因此

k2

将具有未修改的散列值）。有趣的是，我想知道一个键冲突场景，如果整数匹配，只需对与整数关联的唯一键进行文本比较，但这些查询可能会变得很快，可能会很慢。GUID听起来很有趣，给定的文本键是否总是相同的GUID？它会如何影响性能从在此整数标识符上执行多个联接到使用GUID作为表之间的外键？它与仅使用当前文本键本身有何区别？当前文本键本身通过编程强制为唯一？您的GUID将是主键，因此，与您自己生成的63位键相比，您在这方面的联接开销更小。GUID只有16位。在非常大的数据集上，排序可能会很慢，因为guid不是顺序的，但除此之外是非常好的，这是一种行业惯例。没有给定的文本键不会“生成”相同的guid，它们总是随机且唯一的。它的不同之处在于它是唯一的，并且您不必想出算法来确保它，或者说cr吃它。它已经内置了，几乎每种语言都有，包括SQLOrry，希望我进一步的问题不会让人讨厌，但是如果GUID在每次插入时都是唯一（每个系统）创建的，那么它离使用唯一（每个系统）并不遥远整数，它们仍然会重叠，对吗？我认为我真正的问题在于，在系统A和B中，当有时这些键从A复制到B时，甚至还有一个“生成键”的选项。在这种情况下，GUID也会有同样的问题。因此，如果无法处理哈希冲突，问题只是整体配置。（但我真的很欣赏GUIDs的教育！！）@John-我为我们的一个客户照看一个系统，该系统由4个不同的db服务器组成，每个服务器每天插入约25K行，在过去3年中，没有冲突。在这种情况下使用GUID是一件好事。是的，50亿次冲突中有一次可能有一个密钥，但我确信在这之前你会赢得乐透。老实说，系统之间不会有重叠的键。为什么不做一个测试呢？在同一台服务器上创建两个表，同时开始插入，比如在每个表中插入200万行，看看是否有冲突。我打赌不会有冲突，这正是它的美妙之处。在SQL server中，获取GUID的方法是ll函数NEWID（）。关于这个GUID主题，有一份完整的白皮书和论文，最终你可能会遇到一次冲突，但是如果你这样做了，写一篇博客，你可能会成名，这是多么渺茫的机会。在过去的7年里，我一直在关注数千个Db，并做了大量的Db开发，而h我从未见过guid冲突。我通常不使用guid作为PK，但在设计像您这样的系统时，guid就是！