Выбор формата хранения времени?

Question

[Kirill]

Приветствую. У меня вечная проблема выбора формата хранения времени.

Когда лучше использовать DATETIME, когда просто INT для timestamp?
Дату/время рождения - это DATETIME точно, а вот последнее обновление записи в бд? Какими критериями руководствоваться?

Спасибо

Comments

[Пума Тайланд]

Делайте как вам удобно, это же очевидно

[Kirill]

Удобство может потом сильно аукнуться подводными камнями)

[ThunderCat]

masterklass, в точку!

[ThunderCat]

masterklass, Вижу, не сильно опытный, но уже слегка помудревший )

[Пума Тайланд]

masterklass, каким? Если вы не меняете метод хранения данных то ничем не может откликнуться

[Пума Тайланд]

ThunderCat, ну пиздануть без пруфа может любой, а с пруфом слабо?

[Kirill]

Пума Тайланд, не знаю конкретно, они же подводные) Наверное проблемы с хранением дат после 2030 какого-то года

[ThunderCat]

Пума Тайланд, а что пруфить? Что дата должна храниться в формате даты?

[ThunderCat]

Пума Тайланд, простой пример - юникстаймстамп хранит даты с 1970 to 2038 года, как записать дату рождения раньше вышеозначенной даты?

[Пума Тайланд]

ThunderCat, вы прикалываетесь что ли ? это же просто число , инт побольше и можно писать дату сильно больше

[ThunderCat]

Пума Тайланд, позволю себе задать вам тот же вопрос: Прикалываетесь? Если с датой как то надо работать, то ее нужно будет переводить из секунд обратно в дату. Функции конвертации из инт в дату работают с юникстаймстемпом. Если я хочу записать дату рождения человека скажем 1960 года рождения, то в таймстамп не получится это сделать. Ну или "писать свой таймстемп, с преферансом и мадмазелями".

Answer 1

[ThunderCat]

Все очень просто - если это дата и/или время - использовать формат datetime, во всех остальных случаях соответствующие хранимым данным типы. Int для timestamp вообще непотребство в чистом виде.

Дату/время рождения - это DATETIME

У вас хранится время рождения? Тут можно использовать DATE, но я бы не скупился и поставил DATETIME из соображений единообразности работы с датой и временем.

Comments

[Kirill]

А что не так с INT для timestamp?

[Kirill]

Про рождение - это синтетический пример. Для роддома думаю важно и время рождения хранить)

[ThunderCat]

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

[Kirill]

Отображение внутри бд спорный вопрос, всё равно эти данные потом форматируются клиенту под локаль.
Насчет встроенных функций больше согласен.

[Kirill]

Окей, вот реальный пример. Клиент забирает новые/обновляет данные у себя в приложении передавая дату последнего обновления в timestamp формате. Мне кажется лучше тут использовать timestamp для даты последнего обновления записи в БД и делать выборку по нему.

[ThunderCat]

masterklass, в чем принципиальное отличие в данном конкретном случае от даты? Минус одно преобразование формата?
В идеале юзер не должен передавать никакого таймстампа, я туда и 2025 год запендюрить могу самостоятельно. Просто вызывать событие, дата генерируется по событию на сервере.

[Kirill]

Я в данном случае про пользовательское приложение, которое синхронизирует свои данные с сервером. Типа "дай-ка мне всё что случилось с такого-то момента".

[ThunderCat]

masterklass, про выбор формата: я ниже писал, повторюсь - простой пример, - юникстаймстамп хранит даты с 1970 to 2038 года, как записать дату рождения раньше вышеозначенной даты?
А для приложения - оно тоже скорее всего может генерировать не таймстамп, а дату, вы же программно не зависите от функции таймстамп, используйте date() или соответствующую для нужного ЯП.

Answer 2

[Александр Аксентьев]

с нормальной датой работать удобнее и быстрее чем с таймштампом цифрой.
По скорости на моих тестах datetime с индексом против int с индексом, выигрывал первый вариант. Хотя было очевидно что второй должен быть быстрее, оказалось что нет. (В Mysql базе естественно, за другие не скажу).