Database 保存ID与卷的组合

我正在尝试创建一个系统，用户可以在其中创建包含数量更大的产品的杂货清单

背景。

---

我正在设计的应用程序接收一个购物清单，其中包含订购数量更大的产品的ID。用户A订购的杂货清单应可供用户B和所有其他用户使用。用户还可以查看订购最多的杂货清单，每个杂货清单还必须包含该清单中每种产品的数量

（可能的）解决方案。

---

我能想到的一个解决方案是从这些列表中生成一个唯一的散列。取乘积的id，将其与卷相乘，然后将每个值相加，得出此特定列表的哈希值。创建两个表

包含哈希值和用户对此列表排序的次数

使用散列作为唯一id的查找表，包含实际产品的数量

通过这种方式，您可以立即看到排序最多的列表，并可以获得此列表的内容

问题。

---

一个真正的大问题是，在计算列表的哈希值时，我害怕哈希冲突

有没有其他“更简单”或“更好”的方法来解决这个问题，和/或在坚持自己的解决方案时应该使用什么样的哈希算法

编辑1。

---

评论中提出的建议确实可以成为可行的解决办法。然而，仍然有一些事情困扰着我。例如，假设存在一个包含两个项目的列表：包含第2卷的项目a和包含第3卷的项目B。有些人使用此列表即时订购，而其他人则喜欢自己制作列表。使用此解决方案，无法轻松快速地发现以前是否有其他人提交了新列表。在保存列表之前，我必须在更新现有列表或添加新列表之前检查每个现有列表的卷和项是否匹配

---

对于一个包含大约50.000到100.000个列表的数据库来说，这是一个明智的查询问题，还是我在创建这个场景中不存在的问题？

取决于您有多少项。假设您使用了一个好的标准哈希算法，该算法提供了统一的分布，那么只有当您接近sqrt（可能的输出数）时，才会达到较高的冲突概率。因此，一个提供32位值的散列应该适用于数千个条目。切换到64位，您需要有大约40亿个条目才能开始看到哈希冲突

缓解冲突的一种简单方法是，如果不匹配，则在查找后对值进行双重检查，并向哈希和中添加一些值，然后重试

---

您还可以选择更高的位计数，MD5通常用于散列密码。SHA可以为您提供加密保证。但对于您的应用程序来说，这两种方法可能都有些过头了。

也许您有一个原因没有让我们知道，但是散列有什么原因吗？为什么不让一个表

列出

，它有一个唯一的、自动识别主键

list\u id

，该主键指向一个

列表项目

表，该表包含与该列表相关联的所有杂货项目。然后您可以有一个

customer\u list

xref表，其中

customer\u id

和

list\u id

将项目关联在一起。通过这种方式，客户可以拥有多个列表，并且所有内容都是相关的。我认为使其唯一的一个好方法是使用散列。这似乎容易多了。如果我想把频率加到一个列表中，我只需要在列表表中增加一个整数，就可以了。您也可以有其他统计字段，例如：

创建日期

，

更新日期

，

上次使用日期

，

使用频率

，

喜欢

，等等。哈希代码不是唯一的。如果它们是唯一的，就不会有任何哈希冲突。如果你想要一个唯一的标识符，你需要保证它是唯一的。对于低容量数据库，自动增量ID列在这方面做得非常好。对于更高的卷，常用的方法是转换到数据库。我唯一担心的是，如果用户输入一个新列表，则无法快速检查该列表是否已存在于数据库中。我必须检查数据库中的每个条目，然后根据给定的卷检查每个匹配条目。这只是一个项目，想象一下一个包含多个项目的列表。