В базе данных, почему мы не можем только использовать “Длинные” целые числа для дат (millis с эпохи)

Я могу думать по причине, чтобы сохранить дату и время, предшествующие 1 января 1970 года, 00:00:00 по Гринвичу.

Но я чувствую твою боль. Обработка Oracle date / datetime в JDBC болезненна. Это даже несовместимо между разными версиями драйверов!

Должен сказать, что я не обнаружил особых проблем в других драйверах JDBC (других поставщиков БД), хотя ...

Теперь проблема вообще.

Если вам не нужен какой-либо запрос, содержащий вычисления в столбце даты, в этом случае база данных должна иметь понятный ей тип даты.

Возможно, вам это не нужно, поэтому вы можете использовать любое представление, которое вам нравится.

Вы можете использовать целые числа или другие подходящие типы для представления значений даты/времени в вашей базе данных. Однако это создает пару проблем:

• Все ваши текущие и будущие (!!!) приложения (Java или другие), которые используют таблицы базы данных, должны конвертировать между целыми числами базы данных и значениями даты/времени.

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

• Использование целых чисел для представления дат затруднит выполнение специальных SQL-запросов к таблице с использованием столбцов даты.

EDIT

Экономия места при представлении дат в виде целых чисел зависит от базы данных. IIRC, Oracle хранит значения даты/времени как примитивные целые числа. И я ожидаю, что любая приличная РСУБД будет делать то же самое... как для экономии места, так и для эффективности запросов.

Хранение значений даты/времени в виде целых чисел не решает проблему часовых поясов. Это фундаментально сложная проблема.

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

Затем возникает вопрос о гранулярности. (Используя синтаксис даты ISO для ясности) означает ли "1999" то же самое, что "1999-01-01" или "1999-01-01T00:00:00"? А как насчет субсекундной точности?

Дело в том, что никакое простое представление даты/времени (или целого числа) в SQL не может справиться со всем этим. Основная причина ошибок/проблем/сложностей, которые мы наблюдаем, заключается в том, что программисты используют короткие пути в своей реализации и (что более важно) небрежны в своем мышлении.

EDIT 2

Есть еще вопрос, что многие проблемы все еще возникают из-за различий в том, как различные базы данных и их соответствующие драйверы JDBC обрабатывают литералы даты и предположения о часовых поясах. Я не эксперт по JDBC и стандарту(ам) SQL, но корневые проблемы, похоже, следующие:

• Поставщики баз данных не полностью реализовали типы времени даты, как указано в (например) SQL-92.
• Стандарты SQL не определяют единый синтаксис для литералов времени даты, но допускают синтаксис, специфичный для поставщиков баз данных.
• Стандарты SQL разрешают задавать часовой пояс по умолчанию, но при этом нет стандартного способа указать (или даже узнать), что именно задается по умолчанию. Более специфичные для конкретного поставщика решения.
• Спецификация JDBC не предоставляет приложению способа получить или установить часовой пояс по умолчанию, или выбрать синтаксис литерала даты-времени.

Все это приводит к возникновению проблем переносимости и конфигурации для разработчика Java. Однако я не думаю, что это значительно хуже, чем переносимость и проблем с конфигурацией, которые мы получаем с другими аспектами приложений Java / RDBMS. А полностью отказавшись от типов datetime, вы приобретете кучу других проблем; см. выше.

В чем вопрос? Вы спрашиваете, возможно ли это? Это будет зависеть от того, какую базу данных вы используете, но я предполагаю, что это возможно с большинством. Я определенно сделал это с помощью SQL lite в приложениях для Android (которые запрограммированы на Java, если вы с ним не знакомы).

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