在没有 unsigned int 数据类型的情况下存储 unsigned int 的方法的优缺点
我有 64 位无符号整数值，我需要将它们存储在 mongodb 中，它没有无符号整数类型。我看到将它们存储在其他字段类型中并在进出时进行转换的三种主要可能性：
使用有符号 int 可能是最简单且最节省空间的，但缺点是它们不适合人类可读，并且如果有人忘记这样做转换后，其中一些会起作用，这可能会掩盖错误。
对于没有经验的程序员来说，原始二进制文件可能是最难处理的，并且也存在非人类可读性。
字符串表示形式的空间效率最低（unicode 中约 40 个字节，每个字段 8 个字节），但至少所有可能的值都会正确映射，并且为了查询，只需要转换为字符串，而不是更复杂的转换。
我需要从不同的平台获取这些值，因此单个特定于驱动程序的解决方案不是一个选择。
我错过了什么主要的优点和缺点吗？您会使用哪一个？
I have values that are 64-bit unsigned ints, and I need to store them in mongodb, which has no unsigned int type. I see three main possibilities for storing them in other field types, and converting on going in and out:
Using a signed int is probably easiest and most space efficient, but has the disadvantage that they're not human readable and if someone forgets to do the conversion, some of them will work, which may obscure errors.
Raw binary is probably most difficult for inexperienced programmers to deal with, and also suffers from non-human-readability.
A string representation is the least space efficient (~40 bytes in unicode vs 8 bytes per field), but then at least all of the possible values will map properly, and for querying only a conversion to string is required instead of a more complicated conversion.
I need these values to be available from different platforms, so a single driver-specific solution isn't an option.
Any major pros and cons I've missed? Which one would you use?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我只是将数字塞入字符串中。这是最简单、最兼容的解决方案。最常见的编程语言在其标准库中提供字符串到数字的对话。如果其他人稍后需要使用不同的程序读取您的数据库，他们不需要弄清楚您的二进制存储格式。另一个好处是，如果需要，您可以存储大于 unsigned int64 的数字。
I'd just shove the numbers into strings. It's the easiest and the most compatible solution. Most common programming languages provide string to number conversation in their standard libraries. If someone else needs to read your database with a different program later they don't need to figure out your binary storage format. Another bonus is you can store numbers larger than an unsigned int64 if you need to.
我会说使用二进制 - 这是上面唯一的解决方案，在该解决方案中，正确获取查询排序顺序将变得微不足道。
I would say go with binary - it's the only solution above where getting sort orders on queries right is going to be trivial.
为什么字符串值必须采用 unicode 格式？您知道该值始终是数字，因此您可以使用标准 varchar，这意味着不超过 20 个字节。老实说，这实际上取决于如何使用该值。它是否会在使用无符号 64 整数的源的大量连接中使用？如果是这样，则每一行都必须进行转换。它是否仅用于参考或过滤特定值（而不是连接到 mongodb）？如果是这样，那么字符串值将表现得足够好。
如果可能的话，另一种解决方案是在 mongodb 中添加一个 64 位签名 int 列，表示 64 位无符号 int 的签名版本，然后在数据库中使用签名 int 。通过这种方式，您可以加入苹果和苹果，并可以将一个系统的值与另一个系统的值进行比较。
鉴于您所说的，我仍然认为 varchar 列的性能足够好，并且使值具有可读性。
编辑 另一种解决方案是将值存储在有符号的 64 位 int 中，并向您的项目添加一个方法来计算无符号的 64 位值，以便用户可以验证该值。
Why would a string value have to be in unicode? You know the value will always be digits so you can use a standard varchar which means no more than 20 bytes. To be honest, it really depends on how the value will be used. Is it going to be used in lots of joins to the source which is using unsigned 64 ints? If so, there will have to be a conversion on each row. Is it only going to be used for reference or to filter for specific values (as opposed to a join to the mongodb)? If so, then a string value will perform well enough.
Another solution, if it is possible, would be to add a 64-signed int column in the mongodb that represents the signed version of the 64 unsigned int and then use the signed int in your db. In this way you can join on apples and apples and can compare the values from one system to another.
Given what you have said, I still contend that a varchar column will perform well enough and makes the value human readable.
EDIT Another solution would be to store the value in a signed 64-bit int and add a method to your item which calculates the unsigned 64-bit value so that users can verify the value.