数据库设计问题：GUID +自然数
对于我正在构建的数据库，我决定使用自然数作为主键。我知道 GUID 所带来的优势，但是查看数据，大部分行数据都是 GUID 键。
我想从数据库数据生成 XML 记录，自然数的一个问题是我不想将数据库密钥暴露给外界，并允许用户猜测“密钥”。我相信 GUID 可以解决这个问题。
所以，我认为解决方案是生成一个从自然ID派生的稀疏的、唯一的iD（希望它是2路的），或者只是在数据库中添加一个额外的列并存储一个guid（或其他一些多字节id
）派生值更好，因为没有存储损失，但与 GUID 相比，它更容易反转和猜测。
我很好奇其他人在 SO 上做了什么，以及他们有什么见解。
For a database I'm building, I've decided to use natural numbers as the primary key. I'm aware of the advantages that GUID's allow, but looking at the data, the bulk of row's data were GUID keys.
I want to generate XML records from the database data, and one problem with natural numbers is that I don't want to expose my database key's to the outside world, and allow users to guess "keys." I believe GUID's solve this problem.
So, I think the solution is to generate a sparse, unique iD derived from the natural ID (hopefully it would be 2-way), or just add an extra column in the database and store a guid (or some other multibyte id)
The derived value is nicer because there is no storage penalty, but it would be easier to reverse and guess compared to a GUID.
I'm (buy) curious as to what others on SO have done, and what insights they have.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
要计算“GUID”，您可以做的是使用一些盐（例如表名称）计算 ID 的 MD5 哈希值，将其加载到 GUID 中并设置一些位，使其成为有效的 版本 3 (MD5) GUID。
这几乎是双向的，因为您可以让 SQL 计算列（在某些情况下也可以建立索引）保存 GUID，而无需将其保留在表中，并且您始终可以使用正确的 ID 和盐重新计算 GUID，这对于用户来说应该更困难，因为他们不知道盐也不知道实际的 ID。
What you can do to compute a "GUID" is to calculate a MD5 hash of the ID with some salt (table name for instance), load this into a GUID and set a few bits so that it is a valid version 3 (MD5) GUID.
This is almost 2-way since you can have a SQL computed column (which can also be indexed in certain cases) holding the GUID without persisting it in the table, and you can always re-compute a GUID with the correct ID and salt, which should be harder for users since they don't know the salt nor the actual ID.