2

我有一个 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将是最好的选择。

4

2 回答 2

3

我对此表示例外：

这对于代理键来说是有问题的，因为它们是使用最新的自动增量添加到数据库中的，我不希望它们的 ID 依赖于它们插入的顺序。

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

当然，如果您使用摘要（例如 CRC-32），则 Id 的排序顺序毫无意义，但实际上比使用单调递增的 Id 更实用。

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

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

使用计算的散列作为标识符/键确实具有实用性 - 这就是散列表的工作方式，因为它允许您按值快速查找某些内容，而无需实际搜索所有表（例如，要查找 Black Lotus 卡，取就像你做的一样，它的属性的哈希值，然后在 ID 列中查找计算的哈希值，而不必这样做SELECT ... WHERE code = 'A' AND ... AND name = 'black lotus'，但它确实需要你首先知道每个属性值，如果你设置了正确的表索引，这很快就会变得没有意义。

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

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

QED :)

于 2015-03-25T04:07:49.223 回答
0

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

您将看到，对于任何32 位散列和 25K 加值，冲突的几率几乎是十分之一——无论散列算法有多好。

您要么需要一种机制来处理冲突，要么切换到 64 位散列算法。根据这种在各种位大小的1820 万个零冲突样本的crc 冲突， CRC64 似乎已经足够好了 。

于 2015-03-25T04:12:46.153 回答