Плюсы и минусы способов хранения неподписанного типа int без типа данных без знака

Question

У меня есть значения, которые являются 64-битными целыми числами без знака, и мне нужно сохранить их в mongodb, который не имеет типа unsigned int.Я вижу три основных возможности для их хранения в других типах полей и преобразования при входе и выходе:

Использование подписанного int, вероятно, является самым простым и наиболее экономичным, но имеет тот недостаток, что они не читаются человеком.и если кто-то забудет выполнить преобразование, некоторые из них сработают, что может скрыть ошибки.

Сырой двоичный файл, вероятно, наиболее труден для неопытных программистов, а также страдает от нечитаемости человеком.

Строковое представление является наименее эффективным с точки зрения пространства (~ 40 байт в юникоде против 8 байт на поле), но тогда, по крайней мере, все возможные значения будут отображены правильно, и для запроса требуется вместо этого преобразование в строкуболее сложного преобразования.

Мне нужно, чтобы эти значения были доступны на разных платформах, поэтому одно решение для конкретного драйвера не вариант.

Любые основные плюсы и минусыпропущенный?Какой из них вы бы использовали?

Answer 1

Я бы просто засунул числа в строки. Это самое простое и наиболее совместимое решение. Большинство распространенных языков программирования обеспечивают разговор между строками в своих стандартных библиотеках. Если кому-то еще понадобится прочитать вашу базу данных другой программой позже, ему не нужно выяснять ваш двоичный формат хранения. Еще одним бонусом является то, что вы можете хранить числа больше неподписанного int64, если вам нужно.

Answer 2

Почему строковое значение должно быть в юникоде?Вы знаете, что значение всегда будет цифрами, поэтому вы можете использовать стандартный varchar, что означает не более 20 байтов.Если честно, это действительно зависит от того, как будет использоваться ценность.Будет ли он использоваться во многих соединениях с источником, который использует беззнаковые 64 дюйма?Если так, то в каждой строке должно быть преобразование.Будет ли он использоваться только для справки или для фильтрации конкретных значений (в отличие от объединения с mongodb)?Если это так, то строковое значение будет работать достаточно хорошо.

Другим решением, если это возможно, будет добавление столбца с 64 знаками int в mongodb, который представляет версию со знаком 64 без знака int изатем используйте подписанный int в вашей базе данных.Таким образом, вы можете объединять яблоки и яблоки и сравнивать значения из одной системы в другую.

Учитывая то, что вы сказали, я по-прежнему утверждаю, что столбец varchar будет работать достаточно хорошо и сделает значение, читаемое человеком.,

РЕДАКТИРОВАТЬ Другим решением было бы сохранить значение в 64-битном int со знаком и добавить в элемент метод, который вычисляет 64-битное значение без знака, чтобы пользователи могли проверить значение.

Answer 3

Я бы сказал, что идти с двоичным - это единственное решение выше, где получение заказов на сортировку по запросам будет тривиальным.