crc32作为主键的自然键

Question

我有一个TCG卡的数据库，我试图决定一个主键。最初，我用代理键解决了这个问题，但是我意识到，有时候，有些卡片是我忘记添加的，例如促销卡片。这是代理键问题，因为它们以最新的自动增量添加到数据库中，并且我不希望它们的ID依赖于它们插入的顺序。我在想也许我可以对一些卡的功能进行散列，并将其用作主键而不是？

就拿下面的伪代码：

// set code, date released, collector number, name 
$crc = crc32(implode(',', ['A', '1993-08-03', '232a', 'black lotus'])); 
echo $crc; // 4199975187 

的卡的数量可能只徘徊25K左右，现在和成长每6个月左右100-300。

1. 以这样的速度，不会有碰撞的权利？
2. 这是一个很好的做法吗？我有其他好的选择吗？

我知道我可以做的哈希通过将其转换为base 62短，但我将加入到这些用户的库存表所以我想保持这些在int将是最好的选择。

Answer 1

我不同意这样的：

这是与代理键的问题，因为它们被添加到了最新的自动递增的数据库，我不希望自己的ID取决于它们的顺序插入。

ID（正确：“Id”，因为它是一个缩写，而不是初始化）是“Identity”的简称，它具有对每个元素唯一的唯一属性，也就是说，它用于识别每个元素。您不应该附加任何其他含义，因此它随插入顺序单调增加的事实是不相关的，并且通过生成的标识列对数据进行排序没有意义（除非它位于用于查找ID的索引内）。在这种情况下，您应该将Ids视为不透明的手柄。

当然，如果你使用摘要（比如CRC-32），Ids的排序顺序是没有意义的，但实际上比单调递增的Id表现得更少。

您正确识别了散列冲突的风险，CRC-32的范围空间仅为32位，如果您拥有25,000个卡片，则生日问题会告诉我们在如此小的范围内散列冲突的几率空间不是微不足道的。

只需使用自动生成的Id值。 :)

使用计算的散列作为标识符/键具有实用性 - 这就是散列表的工作方式，因为它允许您快速查找某个值，而无需实际搜索所有表（例如查找黑莲花牌，像你一样对其属性进行哈希处理，然后在ID列中查找计算出的哈希值，而不必执行SELECT ... WHERE code = 'A' AND ... AND name = 'black lotus'，但它确实需要您先知道每个属性值，并且如果设置了正确的表索引这很快就变得没有意义了。

与使用散列作为主键的主要问题是：

1. 主键应该是不可变的（“永不更改”）
2. 现在关键取决于数据
3. 如果数据发生变化（例如“blcak lotus”变成“Black Lotus”），那么这个密钥是无效的并且必须被重新创建，但是你不能这么做，因为密钥是不可变的......将以前计算的Id无效。

QED :)

Answer 2

研究此链接： - http://preshing.com/20110504/hash-collision-probabilities/

你会看到，任何 32位散列和25K加重视碰撞近1比10的赔率 - 不管哈希算法有多好。

您需要一种处理冲突或切换到64位散列算法的机制。根据这个 crc collisions at various bit sizes，CRC64似乎是足够好的，有1820万个没有碰撞的样本。