Почему у PostgreSQL и MySQL точность даты только до микросекунд?

Question

[Веня Бабийман]

Точность хранения даты в разных реляционных БД отличается:

+--------------+-------------------------------+----------------+
| Oracle       | 2001-01-01 23:59:59:999999999 | наносекунда    |
| MSSQL        | 2001-01-01 23:59:59:9999999   | сто наносекунд |
| MySQL        | 2001-01-01 23:59:59:999999    | микросекунда   |
| PostgreSQL   | 2001-01-01 23:59:59:999999    | микросекунда   |
+--------------+-------------------------------+----------------+

Что мешает MSSQL, MySQL, PostgreSQL поддерживать точность даты до наносекунд, как Oracle?

Answer 1

[Петр]

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

Comments

[Веня Бабийман]

Повышенная точность требует повышенные ресурсные затраты.

На каких источниках информации базируется тезис?

[d-stream]

Веня Бабийман, полагаю что достаточно здравого смысла.

[Петр]

Веня Бабийман, Для примера, на "здравом смысле" )) Возьмем визуальную интерпретацию числа для указания части часа. Целое число "десять" будет представлено 2 символами "10", а уже более точное представление потребует спецмаркер - "точку" и символы для указания этой экстра информации - 10.00 Вот уже появились дополнительные затраты.

[Веня Бабийман]

d-stream,

полагаю что достаточно здравого смысла.

Этот ответ не касается затронутой темы. Это бесполезный ответ.
Удивляюсь, что кому-то понравился этот ответ.
Попробуйте помочь мне найти авторитетный источник информации, который даст достоверный ответ на заданный вопрос.

[Веня Бабийман]

Петр,

Для примера, на "здравом смысле" ))

Подобный ответ характеризует не достаточный уровень знаний.

[Петр]

Веня Бабийман, Отсутствие специфичных знаний не проблема, а вот отсутствие культуры - это проблема.

[Веня Бабийман]

Петр,

Отсутствие специфичных знаний не проблема, а вот отсутствие культуры - это проблема.

Тезис не по теме вопроса.

[Melkij]

Вопрос "зачем это надо" на самом деле и является ответом. Почему вы не требуете от оракла хранение пикосекунд?

Почему вы смотрите только минимальную дискретность? Посмотрите ещё минимальные и максимальные значения, а так же требуемые для этого размеры структуры данных. Это всё имеет свою цену. Вам необходимо место для хранения (maxvalue - minvalue)/дискретность. Чем меньше дискретность - тем вам нужно больше ресурсов для хранения, чтения/записи и обработки. Это вполне очевидно.

В оракле timestamp - 11 или 13 байт.
В postgresql - 8 байт.
mysql - 4 байта + до 3 байт на хранение долей секунды (вы по "timestamp 4 байта" уже догадались о проблеме 2038?)
Итого в сырой ёмкости записанных данных один и тот же набор данных займёт в оракле в 1,5 раза больше места чем в postgresql.
Действительно надо сделать одинаково плохо всем увеличив размер данных? А если мы работаем с астрономами и им этот крохотный диапазон с 4713 BC по 294276 AD бесполезен полностью? Увеличим и эти даты тоже? Ну и пусть каждый таймштамп будет в килобайт размером, зато его же хватит всем.

[Веня Бабийман]

Вопрос "зачем это надо" на самом деле и является ответом.

1. Зачем я знаю. Вопрос: почему?
2. На размер поля влияет регулируемая точность для секунд (от 0 до 9).
3. Согласно док. Oracle timestamp 7 to 11 bytes, depending on the precision.
4. Встречал применение наносекунд в человеческом быту, а пикосекунд не доводилось.

Я понял. Ваш вариант ответа: потому, что размер.

Answer 2

[jcmvbkbc]

Что мешает MSSQL поддерживать точность даты до наносекунд

То что в винде все встроенные таймстемпы имеют точность 100нс. Потому что формат данных FILETIME -- это целое число сотен наносекунд прошедших с начала 1601 года.

Comments

[Веня Бабийман]

Пардон. Задал вопрос не совсем точно.
Уточнение: вопрос для MSSQL, MySQL, PostgreSQL, Oracle установленных и работающих под ОС Microsoft Windows (x64).

Answer 3

[GamaleyVV]

В Delphi нормальное решение - целая часть: Года черти откуда, дробная часть Время - по делфийским понятиям Float. Куда точней...

Comments

[Веня Бабийман]

Вопрос о типах данных хранения даты для разных реляционных СУБД.