Должны ли даты храниться как Datetime или как int в SQL?

Question

Я храню все свои даты для публикации на моем форуме в datetime (0000-00-00 00:00:00). Я вижу, что phpBB, punBB и все популярные форумы хранят даты в int?

Что лучше?

Answer 1

Если вы храните даты как INT, тогда каждое приложение или инструмент, который когда-либо подключается к вашей базе данных, должен знать, как преобразовать этот INT в нечто значимое. Я бы предложил придерживаться типов данных, которые соответствуют данным, если только у вашей конкретной СУБД нет серьезных недостатков с конкретным типом данных.

Еще одна проблема, которую следует рассмотреть ... если вы сохраните их как INT, вы также потеряете доступ ко многим функциям, связанным с датой, и вам придется написать их самостоятельно. Например, возвращая название дня (понедельник, вторник и т. Д.) Определенной даты.

Answer 2

Я не уверен, что есть "лучший" ответ. Но я бы порекомендовал datetime, потому что, если вы сохранили их как int, у вас могут возникнуть проблемы с Year 2038.

Answer 3

Также существует проблема с датами до эпохи. Сохранять что-то вроде даты рождения участника в INT сложно, поскольку некоторые участники могут родиться до 1 января 1970 года.

Answer 4

Я использую DATETIME для всех своих временных полей (и, используя MySQL, я всегда избегаю TIMESTAMP). Однако я использую один трюк, чтобы установить для столбца значение NULL DEFAULT NULL. Таким образом, мне не нужно беспокоиться или проверять «0000-00-00 00:00:00» в тех случаях, когда я считаю дату пустой или пустой; Я проверяю только на IS NULL.

Единственная причина, по которой я могу думать о том, что в прошлом люди, возможно, рассматривали возможность использования INT для своих столбцов даты, заключается в том, что когда-то DATETIME (и DATE и TIME) были внутренне реализованы MySQL как строки. В этом контексте поля DATETIME будут намного больше, чем поля INT, и поэтому, если пространство является проблемой, я мог бы видеть, что это решение принимается. В наши дни это уже не так (я бы сказал, MySQL 4.x и выше), и нет веских причин больше не выбирать DATETIME.

Answer 5

В настоящее время большинство СУБД позволяют вам выполнять более забавные запросы к полям реальной даты и времени. С помощью функций, доступных для манипулирования датами и запросов, трудно оправдать использование целых чисел.

Я бы предположил, что большинство систем BB используют INT, поскольку их легче реализовать на нескольких ядрах базы данных, и если вам важна только часть даты, а не часть времени, вы можете получить незначительно лучшую производительность от INT, в отличие от к текущему времени (которое обычно составляет 8 байтов).

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

Answer 6

Внутренняя дата и время - это целое число, количество секунд или миллисекунд от некоторой эпохи , часто от эпохи Linux в полночь 1 января 1970 года.

Но он позволяет вам использовать всевозможные замечательные функции даты для сложения, вычитания и декомпозиции интервалов времени, которые вы не можете сделать с помощью int (без переписывания всех этих функций самостоятельно).

Таким образом, вы ничего не теряете и получаете много, как ответили другие, используя дату / дату / время вместо целого.

Answer 7

Лучший ответ "это зависит". Учитывая отсутствие другой информации, я бы сказал, что дата и время лучше. Я рассматриваю реализацию этих форумов как неспособность распознавать более совершенные и более зрелые типы данных. Вы должны были бы найти действительно вескую причину, по которой вы хотели бы получить целые числа вместо даты. Может быть, они есть, а я просто не знаю.

Answer 8

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

Answer 9

Я хочу проконтролировать ответ tpdi и описать свой опыт, проделав это в обоих направлениях несколько раз.

Когда используется целое число, это делается с помощью соглашения, описанного tpdi - заданное количество секунд после некоторого момента времени около 1970 года.

Когда многие производственные программы были хотя бы частично написаны на C, этот режим был стандартом (в стиле UNIX), и было предоставлено достаточное количество функций для отображения и вычисления даты.

Одна проблема, которая не обсуждалась выше, заключается в том, что интерполяции по часам, минутам и секундам не одинаково хорошо обрабатываются всеми языками и библиотеками СУБД. Целочисленные даты обрабатывают это более красиво, не беспокоясь об ошибках округления - по крайней мере, до тех пор, пока вам не нужно разрешение менее 1 секунды. Также полезно не иметь дело с датами до 0, хотя это может быть выполнено без особых проблем с отрицательными целыми числами.

Конечным преимуществом может быть то, что большинство языков / СУБД имеют функцию для обработки этого соглашения, которая упрощает использование нескольких языков и продуктов СУБД с меньшим количеством проблем совместимости.

В некоторых разумных случаях это как @tpdi desribes; но его также можно перевернуть с ног на голову - вы можете потерять точность и межязыковую совместимость через библиотеки, которые обрабатывают целочисленные значения даты и времени, если они соответствуют вашему контексту.

Answer 10

В SQL 2008 введен тип данных «date», который меньше полного поля «datetime», если вам не нужна часть времени (которая, если вы думаете об использовании INT, звучит так, будто в любом случае это не нужно).

Подробнее см. в этой статье .