Yii2 тип поля (MySQL) int или timestamp для времени?

Question

[Arman]

ДД.
Все миграции, код yii2 в основном заточен на INT(). да, шустрее, но пользоваться сложнее. Новые модели начал на timestamp и "new \yii\db\Expression('NOW()')", теперь получил два варианта и надо или половина кода Yii унаследовать и переделать или использовать, как они, int тип.

Как у вас с этим? на github посмотрел, вроде многие остались на int.

Comments

[AlikDex]

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

[German Jet]

AlikDex: не знаю, как принято в сообществе, но поддерживаю

[Arman]

AlikDex: простите, но что-то не понял о чем вы. Я отключил вообще update_at, у меня только created_at на моделях, я говорю про остальные части, если переносить логи, переводы, сессии, rbac в БД то на всех миграциях юзают int(), любые расширения опять же int(), когда в БД смотришь, то не понимаешь что за фигня, должен под рукой держать код, чтоб понять сколько секунды было с утра. А так можно запрос сделать самому WHERE created_at >= "2017-02-01 00:00:00", а с целыми числами? только наверно через функции какие-то mysql, геморр новый какое-то =) вот решил и узнать как люди делают, уходят от int() или мне нужно лучше к нему присмотреться

[AlikDex]

Arik: люди для всяких created_at и тому подобных используют timestamp.

Answer 1

[Максим Тимофеев]

Это извечный спор. Истина в том, что в том или ином случае удобнее тот или иной формат, но если будущее проекта туманно и не предсказуемо - лучше использовать для дат datetime

Answer 2

[Dmitry Bay]

я стал использовать datetime везде. намного удобнее в плане работы.

А так, сколько людей, столько и мнений. По поводу datetime впервые увидел на форуме, и решил перейти с int на него. получилось хорошо.

Comments

[AlikDex]

сколько байт занимает datetime в мускуле?

[Евгений Бухарев]

datetime или timestamp ?

[Dmitry Bay]

AlikDex: а какая разница для удобства? В 99% случаев, размер datetime и его конвертирование в int (а вроде этим mysql и занимается) неважно.

[Dmitry Bay]

evgenybuckharev: я про datetime.

[AlikDex]

Дмитрий Байчапанов: дак большая разница. Лично у меня были случаи, когда при правильной расстановке типов данных база сжималась с 1.4гб до 290 мб. Такойже как вы горе программист, которому "удобно" говноделил. Для справки. datetime поле занимает 8 байт на значение. Timestamp 4 байта, также как и int. К тому же для timestamp доступны функции работы со временем (не все, но этого хватает).

[Dmitry Bay]

AlikDex: у вас там была база данных из чисел и вы datetime в timestamp превращали дважды. Сначала в 700 мб, потом 300мб? Хороший вы архиватор написали для бд.

Вы читать подробнее ответ не думали? Я спросил какая разница, если в 99% случаев по требованиям задачи нет необходимости экономить базу.

Зато вы видимо профессионал, так как записываете человека в говнокодеры лишь потому, что решили выпендриться некоторыми своими знаниями.

[AlikDex]

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

Профессионалом себя не считаю. Но такие советы как ваши вымораживают. Верх некомпетентности, даже для джуниора.

у вас там была база данных из чисел и вы datetime в timestamp превращали дважды. Сначала в 700 мб, потом 300мб? Хороший вы архиватор написали для бд.

У нас там была база статей, с неправильными типами данных. Такойже чудило как вы "вопрос экономии не стоит" сделали на created_at updated_at datetime. Там где можно обойтись tinyint(1 байт) он использовал просто int(4 байта). Хеши не char(32), а varchar(32) + 1. И такого говна просто валом. Вопрос про экономии же не стоит. И вот база из 300мб. превращается в 1.4гб и не влазит в хостинг за 10 долларов с 2гб оперативки. Нужно тратить 40, в месяц.

[Dmitry Bay]

"Такойже чудило как вы"
Поучитесь уважению к незнакомым людям. Пригодится в будущем.

Судя по вашим словам, разработчики - идиоты, которые зря придумали datetime, когда можно обойтись инт.

Я еще раз повторяю, раз вы не умеете читать - в 99% случаев, это неважно.
4 байта сэкономленных на одной строчке - 1 млн строк на 4 мб (да я округляю тут, что тоже в текущем контексте неважно), покрывается 2-3 картинками среднего качества. Или каталог статей не содержит картинок?


А уж если проект требует оптимизации под какие-то специальные условия, то эти условия должны изначально задаваться в ТЗ.

[AlikDex]

4 байта сэкономленных на одной строчке - 1 млн строк на 4 мб (да я округляю тут, что тоже в текущем контексте

Вот она, недальновидность и некомпететность.
в одной строке может быть как одно такое значение, с неправильно выбранным типом, так и 100 значений. Отсюда и непонимание.

Судя по вашим словам, разработчики - идиоты, которые зря придумали datetime, когда можно обойтись инт.

Судя по моим словам, нужно целесообразно выбирать, какой тип данных подойдет в конкретном случае. Делать datetime для created_at и updated_at в 99% случаях идиотизм. 1% оставим на исключения, но в моей практике такой надобности никогда не было.

А уж если проект требует оптимизации под какие-то специальные условия, то эти условия должны изначально задаваться в ТЗ.

Навалю кучу, скажу "это ваше". В тз было так, а не иначе. Все понятно.
В целом, если брать во внимание твои слова:

По поводу datetime впервые увидел на форуме, и решил перейти с int на него. получилось хорошо.

становится понятен ход мыслей. Подсмотрел у другого говнодела и начал делать также. Вместо этого, советую иногда читать best practices, а не перенимать у всяких дурацкие идеи. Чтобы потом продолжить их распространять.

[Dmitry Bay]

"Вот она, недальновидность и некомпететность.
в одной строке может быть как одно такое значение, с неправильно выбранным типом, так и 100 значений. Отсюда и непонимание."

Вы серьезно тут? Я пример на одном значении привожу и как он влияет в целом на проект. А вы тыкаете сразу в то, что значений может быть и 100. Вы уточняйте, 100 столбцов в одной таблице или многих, а то я ведь тоже могу подумать, что у вас столь широкие таблицы.
И заметьте, я ни слова не говорил про created_at updated_at. Это вы уже напридумывали, чтобы доказать свою крутость. Читайте внимательно. Если чего то не написано, вероятнее всего это подразумевается.

У вас кажется очень повышенное чувство ЧСВ. Судя по вашим ответам, можно вообще и фреймворки в задницу засунуть разработчикам, так как писать нужно на чистом php, потому что это будет экономить место. о боже, целых 25мб или 15 картинок...
Иначе говоря - всегда есть куда экономить. Экономить можно на всем.

[Евгений Бухарев]

Странно что в этом сраче нет ни слова о том что значения в timestamp хранят в основном в тех случаях когда важна информация о часовом поясе, а в случая с datetime эта информация не хранится

[Dmitry Bay]

evgenybuckharev: В этом сраче был бы уместнее срач - UTF-8 или CP-1251, использовать ли UTF-8 general_ci и тд, а временные зоны - это уже совмес другая история=)