Тип даты
Тип даты
Почему-то я смотрю во всех примерах yii, в доках и в самом фреймворке все заточено под использование в качестве типа даты/времени обычного int (в базе). Почему так? В MySQL есть еще типы DATETIME, DATE, TIME, и даже специальный TIMESTAMP для этого. Но используется именно int. Он что меньше места занимает? Или есть еще какие-то причины? Просто мне кажется использовать DATETIME удобнее. Даже просто открыв базу в какой-нибудь программе просмотра сразу видишь даты, а не простые числа по которым ничего не понять пока не сделаешь FROM_UNIXTIME. Также в MySQL есть всякие функции и операции для работы именно с датами.
P.S. Да и в PHP есть DateTime уже давно (аж с 5.2). Почему бы не маппить в него? Вне зависимости от представления в базе.
P.S. Да и в PHP есть DateTime уже давно (аж с 5.2). Почему бы не маппить в него? Вне зависимости от представления в базе.
-
- Сообщения: 50
- Зарегистрирован: 2017.03.06, 15:37
- Откуда: Владивосток
Re: Тип даты
Я думаю, это просто дело привычки ещё с далёких времён.
Лично я уже довольно давно ушёл от int к DATE и DATETIME.
Плюс, храню и работаю со времем в UTC, чтобы не было проблем как при обработке, так и при понимании "а какой же там часовой пояс?".
В базе, разумеется, все даты или в DATE, когда время не важно, или в DATETIME.
Ещё один минус времени в int - это минимум 1970-01-01 = время старта UNIXTIME.
Неявная конвертация int в date - это неправильно.
Потому что всё, что неявно - всё потом может аукнуться.
Лично я уже довольно давно ушёл от int к DATE и DATETIME.
Плюс, храню и работаю со времем в UTC, чтобы не было проблем как при обработке, так и при понимании "а какой же там часовой пояс?".
В базе, разумеется, все даты или в DATE, когда время не важно, или в DATETIME.
Ещё один минус времени в int - это минимум 1970-01-01 = время старта UNIXTIME.
Неявная конвертация int в date - это неправильно.
Потому что всё, что неявно - всё потом может аукнуться.
Re: Тип даты
1. Кстати да - прочитал что DATETIME в MySQL хранит без учета пояса. Это как-бы минус имхо... В таймстампе есть информация о поясе и всегда можно получить время с нужным поясом.frid-karatel писал(а): ↑2019.03.05, 16:08 Я думаю, это просто дело привычки ещё с далёких времён.
Лично я уже довольно давно ушёл от int к DATE и DATETIME.
Плюс, храню и работаю со времем в UTC, чтобы не было проблем как при обработке, так и при понимании "а какой же там часовой пояс?".
В базе, разумеется, все даты или в DATE, когда время не важно, или в DATETIME.
Ещё один минус времени в int - это минимум 1970-01-01 = время старта UNIXTIME.
Неявная конвертация int в date - это неправильно.
Потому что всё, что неявно - всё потом может аукнуться.
2. По поводу 1970 тоже не вижу проблемы. Ты часто используешь даты меньше 1970? Я ни разу не использовал. Это разве что какие-то исторические данные хранить...
3. Ну пусть не неявно. Пусть было бы какое-нибудь поведение которые бы делало это. Как TimestampBehaviour.
4. Вот кстати. Как ты юзаешь DATETIME если все во фреймворке заточено под int? Ну например вспомнить хоть это поведение: TimestampBehaviour - оно работает только с int. Использую его почти в каждой модели. Или например в гридах где выводится время с помощью форматтера Yii - оно выводится из int-вого поля. Все эти штуки не будут работать с DATETIME скорее всего.
-
- Сообщения: 50
- Зарегистрирован: 2017.03.06, 15:37
- Откуда: Владивосток
Re: Тип даты
Уже лет как 5 использую PostgreSQL, а там с зонами проблем нет
В MySQL, насколько помню, тоже при определённом подходе всё ОК - настройку СУБД выкрутить в нужную зону, и всё.
Главное - помнить, что там LOCALTIME - это UTC.
Потому что по умолчанию там пояс сервера.
Ну а как же даты рождения?
А как же нулевые (0000-00-00) даты, когда столбец NOT NULL?
Или те же даты, приходящие, скажем, из 1С, где нулевая дата - это 0001-01-01?
Никто не мешает написать свой
И да, там есть атрибуты как раз для указания нужных значений, хоть BOOL писать можно.
Но ИМХО лучше переопределить, чтобы постоянно эти атрибуты не указывать.
Честно - давно уже не использую grid'ы, так как зачастую запросы куда сложнее, чем могут обработать grid'ы.Brainfuck писал(а): ↑2019.03.05, 16:23 4. Вот кстати. Как ты юзаешь DATETIME если все во фреймворке заточено под int? Ну например вспомнить хоть это поведение: TimestampBehaviour - оно работает только с int. Использую его почти в каждой модели. Или например в гридах где выводится время с помощью форматтера Yii - оно выводится из int-вого поля. Все эти штуки не будут работать с DATETIME скорее всего.
Плюс не нравится plain-код и обращения к атрибутам через текст.
Использую обычные таблицы и обращаюсь к объектам не через магию.
Последний раз редактировалось frid-karatel 2019.03.05, 16:48, всего редактировалось 2 раза.
- proctoleha
- Сообщения: 298
- Зарегистрирован: 2016.07.10, 19:00
Re: Тип даты
Неправда, открываем TimestampBehavior и читаем :
А по поводу типа int: на локальном сервере часовой пояс Москва, на продакшене UTS. Но, т.к. я храню время в int, мне на это все равно.* If your attribute names are different or you want to use a different way of calculating the timestamp,
* you may configure the [[createdAtAttribute]], [[updatedAtAttribute]] and [[value]] properties like the following:
*
* ```php
* use yii\db\Expression;
*
* public function behaviors()
* {
* return [
* [
* 'class' => TimestampBehavior::className(),
* 'createdAtAttribute' => 'create_time',
* 'updatedAtAttribute' => 'update_time',
* 'value' => new Expression('NOW()'),
* ],
* ];
* }
Вот за что я не люблю линукс, так это за свои кривые, временами, руки
Re: Тип даты
@frid-karatel,
1. Что значит проблем с зонами нет? Если этот тип не хранит информацию о зоне то никакие настройки этого не исправят.
2. Хмм, да с датами рождения пожалуй может возникнуть проблема. Просто мне еще не приходилось их обрабатывать. Впрочем 1970 - это уже почти полтос человеку)))) Маловероятно что люди старше будут юзать сайт. А пройдет еще полтос лет и уже точно не будут. Но да - так-то для этого пожалуй таймстамп не проканает в идеале.
А нулевые даты надо записывать именно как NULL! Если есть такая необходимость - значит надо сделать столбец nullable. Впрочем с int-ом тоже не вижу проблемы - записываешь 0 и все. Он потом отображается как 1970. Это конечно неприятно, но терпимо. А лучше все-таки сделать nullable столбец и писать null.
Понятия не имею про 1С. Меня от одного упоминания этой гадости передергивает. Не работал, не работаю и не буду работать с ним.
3. Вот в том то и дело. Можно и фреймворк свой написать, но хочется чтобы все было из коробки.
4. А я считаю виджеты (и гриды в частности) самой главной фичей Yii2 из всех. Из-за этого я до сих пор не перешел на Laravel. Потому что нигде больше нет такой удобной штуки. Готовая бутстраповская верстка - это топ. Я сам верстаю плохо, но интерфейс делать как-то надо - и виджеты просто спасение. Это как компоненты в реакте - принцип тот же. Я от них просто тащусь...
1. Что значит проблем с зонами нет? Если этот тип не хранит информацию о зоне то никакие настройки этого не исправят.
2. Хмм, да с датами рождения пожалуй может возникнуть проблема. Просто мне еще не приходилось их обрабатывать. Впрочем 1970 - это уже почти полтос человеку)))) Маловероятно что люди старше будут юзать сайт. А пройдет еще полтос лет и уже точно не будут. Но да - так-то для этого пожалуй таймстамп не проканает в идеале.
А нулевые даты надо записывать именно как NULL! Если есть такая необходимость - значит надо сделать столбец nullable. Впрочем с int-ом тоже не вижу проблемы - записываешь 0 и все. Он потом отображается как 1970. Это конечно неприятно, но терпимо. А лучше все-таки сделать nullable столбец и писать null.
Понятия не имею про 1С. Меня от одного упоминания этой гадости передергивает. Не работал, не работаю и не буду работать с ним.
3. Вот в том то и дело. Можно и фреймворк свой написать, но хочется чтобы все было из коробки.
4. А я считаю виджеты (и гриды в частности) самой главной фичей Yii2 из всех. Из-за этого я до сих пор не перешел на Laravel. Потому что нигде больше нет такой удобной штуки. Готовая бутстраповская верстка - это топ. Я сам верстаю плохо, но интерфейс делать как-то надо - и виджеты просто спасение. Это как компоненты в реакте - принцип тот же. Я от них просто тащусь...
Re: Тип даты
А, ну да. Ок. Кстати посмотрел - форматтер тоже работает с DateTime. Интересно... Может где-нибудь сыщется и поведение для автоматической конвертации в DateTime.proctoleha писал(а): ↑2019.03.05, 16:46 Неправда, открываем TimestampBehavior и читаем :* If your attribute names are different or you want to use a different way of calculating the timestamp,
* you may configure the [[createdAtAttribute]], [[updatedAtAttribute]] and [[value]] properties like the following:
*
* ```php
* use yii\db\Expression;
*
* public function behaviors()
* {
* return [
* [
* 'class' => TimestampBehavior::className(),
* 'createdAtAttribute' => 'create_time',
* 'updatedAtAttribute' => 'update_time',
* 'value' => new Expression('NOW()'),
* ],
* ];
* }
-
- Сообщения: 50
- Зарегистрирован: 2017.03.06, 15:37
- Откуда: Владивосток
Re: Тип даты
Ну я и говорю, что давно это было, сейчас с MySQL уже не работаю, за очень редким исключением.
Есть ещё всякие события а-ля Великая Отечественная Война и т.п.
Да и много каких дат есть, которые старше 1970 года.
Как бы тут сказать... есть те, кто за NULL, а есть, кто против.
NULL создаёт проблемы его использовании, например, различные условия типа create_stamp > NOW().
Что условие "больше", что условие "меньше" не вернёт ничего, так как NULL - особенный тип.
Re: Тип даты
Много дат, но немногие проекты их хранят.frid-karatel писал(а): ↑2019.03.05, 17:10Есть ещё всякие события а-ля Великая Отечественная Война и т.п.
Да и много каких дат есть, которые старше 1970 года.
Как бы тут сказать... есть те, кто за NULL, а есть, кто против.
NULL создаёт проблемы его использовании, например, различные условия типа create_stamp > NOW().
Что условие "больше", что условие "меньше" не вернёт ничего, так как NULL - особенный тип.
NULL никак не мешает сравнению. Пруф
-
- Сообщения: 50
- Зарегистрирован: 2017.03.06, 15:37
- Откуда: Владивосток
Re: Тип даты
Потому, что в Yii вообще нет такого мэппинга. Только примитивы (int)$integer, (float)$double и (bool)$boolean. И недавно добавили JSON в array. Все остальные поля DATE, DATETIME так и достаются в сырой string.Brainfuck писал(а): ↑2019.03.05, 15:31 Почему-то я смотрю во всех примерах yii, в доках и в самом фреймворке все заточено под использование в качестве типа даты/времени обычного int (в базе)... Да и в PHP есть DateTime уже давно (аж с 5.2). Почему бы не маппить в него? Вне зависимости от представления в базе.
Кому нужно пишут свой мэппинг сами в afterFind/beforeSave или в поведении.