@phpgeeks - страница 76 - Telegram web archive

Ridosh

Int

Ridosh

Временную зону на клиенте конвертируешь

Ridosh

С разницей от серверной

Chuvi

datetime, потому что нативное поле и всё работает прозрачно.

𝓐rtem

datetime, потому что нативное поле и всё работает прозрачно.

а что насчет зоны? или это timestamp сохраняет в базу с учетом времени? datetime сохраняет без учета?

𝓐rtem

Int

Какие минусы у этого метода хранения в отличие от того же datetime?

Chuvi

а что насчет зоны? или это timestamp сохраняет в базу с учетом времени? datetime сохраняет без учета?

от зоны серваера. Для каждого проекта индивидуально обычно.

𝓐rtem

ну т.е хранить в int это норм практика?

Chuvi

ну т.е хранить в int это норм практика?

норм, просто придётся работать как с int а не как с объектом.

Chuvi

ну т.е хранить в int это норм практика?

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

𝓐rtem

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

𝓐rtem

Просто я столкнулся с тем, что grafana не понимает дату в виде интового значения, судя по всему

𝓐rtem

а дату как дату - вроде хавает адекватно

𝓐rtem

Но мне не очень хочется хранить ее в виде строки и доставать постоянно один тип и заниматься его переводом в другой вид

Chuvi

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

Строка Timestamp однозначна (в ней есть timezone), int - нет.

Chuvi

Решение стоит принимать исходя из данных проекта. Если Timezone важен, то лучше хранить переменнную Timezone пользователя в данных пользователя. Её проще использовать при создании и работе с объектом. Это обычно не важно, если проект локализован. Например для одного города или часового пояса.

Chuvi

Ну и напоследок. Если проект только для русских - дешевле хранить int и смещение в ячейке пользователя. Размер данных меньше.

Мой

в дебиане 8 ссш для рута выключили. Час пытался понять почему после обновления не могу подключиться

Eugene Goose

=)

Sergey

Int

зачем int если есть timestamp?

Sergey

Строка Timestamp однозначна (в ней есть timezone), int - нет.

в какой БД?

Sergey

Интереса ради - как ВЫ храните дату в базе? Конкретно до секунд. Имею ввиду в каком типе данных? Какие плюсы и минусы? Находил даже плюсы где-то на стаковерфлоу за тип (int) Что правильнее и надежнее? И как потом с этим типом работаете? (Int например можно через date конвертировать, а DATETIME в виде строки идет кажется, что лучше использовать?)

если после 1970, то unix time, иначе в datetime + отдельно временная зона

𝓐rtem

в какой БД?

mysql

𝓐rtem

Временная зона мне в принципе не нужна для хранения

Sergey

ты время как char хранишь?

𝓐rtem

Мне нужно точное число одинаковое у всех

𝓐rtem

не как char, как int

Sergey

откуда тогда там временная зона?

𝓐rtem

В смысле. Я говорю просто - кто как хранит Как лучше Не плохо ли в инте хранить Причем тут ваш вопрос

𝓐rtem

я не говорю что в инте временная зона

Sergey

что тогда такое "строка timestamp"

Sergey

Строка Timestamp однозначна (в ней есть timezone), int - нет.

Chuvi

Строка Timestamp однозначна (в ней есть timezone), int - нет.

DATETIME, опечатался. Ну всмысле не int.

𝓐rtem

что тогда такое "строка timestamp"

Кому вопрос адресуете? Жмите "Reply" вместо "Forward"

Sergey

Кому вопрос адресуете? Жмите "Reply" вместо "Forward"

ты ответил на мой reply другого человека

𝓐rtem

Короче - задача хранить точное число секунд, одинаковое у всех и везде, т.е таймштамп. Вопрос что лучше. Инт или не инт и в чем преимущества

Sergey

лучше timestamp

Chuvi

лучше timestamp

timestamp === int ))) И всегда UTC.

𝓐rtem

timestamp === int ))) И всегда UTC.

Т.е разницы нет?

Sergey

timestamp === int ))) И всегда UTC.

только на уровне диска, СУБД с тобой не согласна

Sergey

на int ты не сможешь временые функции применять

Sergey

а на timestamp без проблем

Chuvi

между полем типа TIMESTAMP и 4х байтным числом - нет.

𝓐rtem

на int ты не сможешь временые функции применять

ты имеешь ввиду временные функции mysql?

Sergey

да

𝓐rtem

ну а так, ничего "ужасного" в инте нет, я понял, спасибо.

Sergey

ничего ужасного для хранения чисел

Chuvi

только на уровне диска, СУБД с тобой не согласна

При хранении, хранится 4х байтное число, при запросе, выводится с учётом настроек СУБД.

Sergey

При хранении, хранится 4х байтное число, при запросе, выводится с учётом настроек СУБД.

SUBTIME на int покажешь?

Chuvi

SUBTIME(FROM_UNIXTIME(int),int) например?

Chuvi

SUBTIME на int покажешь?

Ты вообще ко мне то чо прикопался? Я считаю что надо выбирать исходя из потребностей проекта - и в том и другом случае есть удобства.

Sergey

просто не вижу смысла использовать int сместо timestamp, а у тебя есть знание о причинах, но ты молчишь

Chuvi

А по существу вопроса это и есть ответ - выбери себе как хранить в зависимости от аудитории проекта. Всё. Преимущества можно долго ковырять.

Chuvi

просто не вижу смысла использовать int сместо timestamp, а у тебя есть знание о причинах, но ты молчишь

Если тебе надо ОЧЕНЬ много хранить отметок времени и у тебя пользователи из определённых таймзон, то дешевле хранить int. Размер меньше.

Sergey

так ты определить, меньше или нет разницы

Sergey

между полем типа TIMESTAMP и 4х байтным числом - нет.

Chuvi

http://gpshumano.blogs.dri.pt/files/2009/07/mysql_dt_myisam.jpeg

Chuvi

http://gpshumano.blogs.dri.pt/2009/07/06/mysql-datetime-vs-timestamp-vs-int-performance-and-benchmarking-with-innodb/

Chuvi

int быстрее, из-за навешивания time функций на int - timestamp медленнее. Если ты занимаешься приводом цифр к дате НЕ в базе - int хранить дешевле и быстрее. Достаточно причин?

Sergey

July 6th, 2009 не легко тебе с mysql 5.3

Chuvi

July 6th, 2009 не легко тебе с mysql 5.3

Ты по какой-то причине считаешь что голый int может быть медленнее int'a с навешенными функциями? Не зависимо от версий?