我的值是64位无符号整数，我需要将它们存储在没有unsigned int类型的mongodb中。我看到了将它们存储在其他字段类型中的三种主要可能性，以及进出的转换：
使用带符号的int可能是最简单且最节省空间的，但缺点是它们不是人类可读的，如果有人忘记进行转换，其中一些会起作用，这可能会掩盖错误。
对于没有经验的程序员来说，原始二进制文件可能是最难处理的，并且还具有非人类可读性。
字符串表示的空间效率最低（unicode约为40个字节，每个字段为8个字节），但至少所有可能的值都将正确映射，而对于查询，只需要转换为字符串而不是更复杂的转换。
我需要从不同的平台上获取这些值，因此不能选择单个特定于驱动程序的解决方案。
我错过了哪些重大利弊？你会用哪一个？
答案 0 :(得分：1)
我只是把数字推到字符串中。这是最简单，最兼容的解决方案。最常见的编程语言在其标准库中提供字符串到数字的对话。如果其他人需要稍后使用其他程序读取您的数据库，则无需计算出您的二进制存储格式。另一个好处是，如果需要，您可以存储大于无符号int64的数字。
答案 1 :(得分：0)
我会说二进制 - 这是上面唯一的解决方案，在正确的查询上获取排序顺序将是微不足道的。
答案 2 :(得分：0)
为什么字符串值必须是unicode？您知道该值始终为数字，因此您可以使用标准varchar，这意味着不超过20个字节。说实话，这实际上取决于价值的使用方式。它是否会在使用无符号64个整数的源的大量连接中使用？如果是这样，则每行都必须进行转换。它是仅用于参考还是过滤特定值（而不是与mongodb的连接）？如果是这样，那么字符串值将表现得足够好。
如果可能，另一个解决方案是在mongodb中添加一个64-signed int列，表示64 unsigned int的签名版本，然后在db中使用signed int。通过这种方式，您可以加入苹果和苹果，并可以比较一个系统与另一个系统的值。
鉴于您所说的内容，我仍然认为varchar列的性能足够好，并使该值具有人类可读性。
编辑另一种解决方案是将值存储在带符号的64位int中，并为项添加一个方法，该方法计算无符号的64位值，以便用户可以验证该值。 / p>