Каков наилучший способ хранения дат в MongoDB?

Я только начинаю узнавать о MongoDB и надеяться на медленную миграцию из MySQL.

В MySQL существует два разных типа данных - DATE ('0000-00-00') и DATETIME ('0000-00-00 00:00:00'). В моей MySQL я использую тип DATE, но я не уверен, как перенести их в MongoDB. В MongoDB существует объект DATE, который сопоставим с DATETIME. Кажется, было бы наиболее целесообразно использовать объекты DATE, но это было бы пустым пространством, так как часы, мин, сек не используются. С другой стороны, сохранение даты в виде строк кажется неправильным.

Есть ли золотой стандарт для хранения дат ('0000-00-00') в MongoDB?

Ответ 1

BSON (формат данных хранения, используемый mongo изначально) имеет выделенный тип даты UTC datetime, который является 64-разрядным (так, 8 байт), подписанное целое число, обозначающее миллисекунды с момента времени Unix. Существует очень мало веских причин, по которым вы использовали бы любой другой тип для хранения дат и временных меток.

Если вы отчаянно пытаетесь сохранить несколько байт в день (опять же, с добавлением mongo и минимальным размером блока, и все это только стоит проблем в очень редких случаях), вы можете хранить даты как 3-байтовый двоичный блок, сохраняя это как целое число без знака в формате YYYYMMDD или двухбайтный двоичный код, обозначающий "дни с 1 января года X", где X должен быть выбран соответствующим образом, поскольку это поддерживает только диапазон дат, охватывающий 179 лет.

РЕДАКТОР: Как показано ниже, это всего лишь жизнеспособный подход в очень редких случаях. В принципе; использовать родной тип даты mongo;)

Ответ 2

Я фактически перерабатываю базу данных MongoDB, где даты хранятся как соответствующие типы Date(), чтобы вместо них хранить их как строки в форме yyyy-mm-dd. Почему, учитывая, что каждый другой ответчик говорит, что это ужасная идея? Проще говоря, из-за бесконечной боли, которую я испытывал, пытаясь работать с датами в JavaScript, которая не имеет (реальной) концепции часовых поясов. Я сохранял даты UTC в MongoDB, то есть объект Date() с моей желаемой датой и временем, установленным в качестве полуночного UTC, но он неожиданно усложнен и подвержен ошибкам, чтобы получить датированную пользователем дату, правильно преобразованную в это из любого часового пояса. случается, в. Я изо всех сил пытаюсь заставить код JavaScript "любой локальный часовой пояс для UTC" работать (и да, я знаю Sugar.js и Moment.js), и я решил, что простые строки, такие как хороший старый стандарт MySQL yyyy-mm-dd - это путь, и я буду анализировать объекты Date() по мере необходимости во время выполнения на стороне клиента.

Кстати, я также пытаюсь синхронизировать эту базу данных MongoDB с базой данных FileMaker, которая также не имеет понятия о часовых поясах. Для меня простота просто не хранить данные времени, особенно когда она бессмысленна, как полутоновая UTC, помогает обеспечить код с меньшей ошибкой, даже если мне приходится разбираться с датами строк и из них сейчас.

Ответ 3

Если вы действительно заботитесь о сохранении 4 байта на поле (в случае, если у вас много полей DATE для каждого документа), вы можете хранить даты как int32 в форме 20110720 (примечание MySQL DATE занимает 3 байта, поэтому в любом случае хранение будет больше). В противном случае лучше придерживаться стандартного типа datetime.