mysql - 自然键的crc32作为主键

Question

我有一个 TCG 卡片数据库，我正在尝试确定一个主键。我最初使用代理键解决，但我意识到有时我会忘记添加一些卡片，例如赠卡。这对代理键来说是有问题的，因为它们是用最新的自动增量添加到数据库中的，我不希望它们的 ID 取决于它们插入的顺序。我在想也许我可以对某些卡片功能进行哈希处理并将其用作主键？

以下面的伪代码为例:

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

卡片的可能数量现在徘徊在 25,000 张左右，并且每 6 个月增加大约 100-300 张。

1. 按照这个速度，不会发生碰撞吧？
2. 这是好的做法吗？我还有其他好的选择吗？

我知道我可以通过将哈希值转换为 base 62 来缩短哈希值，但我会将它们加入用户的库存表中，因此我认为将它们保留在 int 中将是最佳选择。

Answer 1

我对此表示反对:

This is problematic with the surrogate key because they get added to the database with the latest auto increment and I didn't want their IDs to depend on the order they were inserted.

ID(正确:“Id”，因为它是缩写，而不是首字母缩写词)是“Identity”的缩写，它具有对每个元素唯一的单一属性，即用于标识每个元素。您不应附加任何其他含义，因此它随插入顺序单调增加的事实是无关紧要的，并且按生成的标识列对数据进行排序是没有意义的(除非它位于用于按 ID 查找的索引中)。在这种情况下，您应该将 ID 视为不透明句柄。

当然，如果您使用摘要(例如 CRC-32)，Id 的排序顺序是没有意义的，但实际上比单调递增的 Id 更实用。

您正确识别了哈希冲突的风险，CRC-32 的范围空间只有 32 位，如果您有 25,000 张卡片，那么生日问题告诉我们在如此小的范围空间中发生哈希冲突的几率不是微不足道的。

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

使用计算的散列作为标识符/键确实有实用性 - 这就是散列表的工作方式，因为它允许您按值快速找到某些东西，而无需实际搜索所有表(例如找到黑莲花卡，像你一样获取其属性的散列，然后在 ID 列中查找计算的散列，而不必执行 SELECT ... WHERE code = 'A' AND ... AND name = 'black lotus' ，但它确实要求您首先了解每个属性值，如果您设置了正确的表索引，这很快就会变得没有实际意义。

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

1. 主键应该是不可变的(“永不改变”)
2. key 现在取决于数据
3. 如果数据发生变化(例如“blcak lotus”变为“Black Lotus”)，则 key 无效且必须重新创建，但您不能这样做，因为 key 是不可变的...呈现先前计算的 Id无效。

QED:)