9

当创建一个 Web 应用程序以某种方式显示重复实体的唯一标识符（YouTube 上的视频，或像我这样的网站上的书籍部分）时，最好使用统一长度标识符，如哈希或唯一标识符数据库中项目的键（1、2、3 等）。

除了透露一些我认为无关紧要的关于你的应用程序内部的信息之外，为什么使用哈希比只使用唯一 ID 更好？

简而言之：哪个更适合用作公开显示的唯一标识符 - 哈希值或数据库中的唯一键？

编辑：我再次提出这个问题，因为 Dmitriy 提出了不将命名绑定到 db 特定属性的好处。这种束缚会阻止我将来优化​​/规范化数据库吗？

该平台使用 php/python 和 ISAM /w MySQL。

4

8 回答 8

5

除非您试图隐藏内部对象 ID 计数器的状态，否则散列会不必要地缓慢（生成和比较）、不必要的长、不必要的丑陋以及不必要的碰撞能力。GUID 又长又丑，使得它们和哈希一样不适合人类消费。

对于类似库存的东西，只需使用顺序（或分片）计数器。如果您迁移到不同的数据库，您只需将新计数器初始化为至少与现有最大记录 ID 一样大的值。几乎每个数据库服务器都为您提供了执行此操作的方法。

如果您试图隐藏计数器的状态，可能是因为您正在计算用户并且不希望竞争对手知道您有多少，我建议避免显示您的内部 ID。如果您坚持显示它们并且不想要散列的缺点，您可以考虑使用最大周期线性反馈移位寄存器来生成 ID。

于 2010-06-12T19:11:55.673 回答
2

如果我不希望用户能够猜测系列中的下一个 ID，我通常会使用哈希。但是对于您的书籍部分，我会坚持使用数字 ID。

于 2008-10-13T04:44:05.600 回答
2

如果由于某种原因需要重建数据库，例如排序发生变化，则最好使用散列。序数会移动——但哈希值会保持不变。

不依赖于你把东西放进盒子里的顺序，而是依赖于东西的属性，看起来……更安全。

但显然要小心碰撞。

于 2008-10-13T05:24:07.547 回答
1

用哈希你

  1. 如有必要，可以自由地将数据库与类似的（或备份）合并
  2. 没有做一些可以帮助一些猜测攻击的事情
  3. 没有透露更多关于用户的私人信息而不是必要的，例如，如果有人在您当前的数据库登录中看到用户号 2，他们会得到他是老歌的信息。
  4. （前提是您使用长散列或 GUID）如果您被 YouTube 收购并且他们决定集成您的数据库，这将极大地帮助您自己。
  5. 帮助自己，以防出现按 GUID 索引的搜索引擎。

请让我们知道过去 6 个月是否让您对这个问题有所了解...

于 2009-06-23T05:19:03.723 回答
0

哈希不保证是唯一的，我相信也不保证是一致的。

于 2008-10-13T04:43:37.270 回答
0

您的用户是否必须记住/使用该值？还是您从安全 POV 中查看？

从安全的角度来看，这无关紧要——因为您不应该仅仅依靠人们不猜测他们不应该看到的东西的不同但有效的 ID 来阻止他们。

于 2008-10-13T05:07:08.457 回答
0

是的，我认为您不是在寻找哈希 - 您更有可能在寻找 Guid。如果您在 .Net 平台上，请尝试 System.Guid。

但是，不使用 Guid 的最重要原因是性能。对（长）字符串进行数据库连接和查找是非常不理想的。数字很​​快。所以，除非你真的需要它，否则不要这样做。

于 2008-10-13T05:23:59.983 回答
0

散列的优点是您可以在对数据库执行任何检查它们是否存在之前检查它们是否有效。这可以帮助您抵御使用随机散列的攻击，因为您不需要使用虚假查找来加重数据库的负担。

因此，如果您的哈希具有某种明确定义的格式，例如末尾有校验和，您可以检查它是否正确，而无需访问数据库。

于 2014-05-23T17:34:32.007 回答