Comments 132
тока вы не путайте одно с другим. вы же записываете в базу значение NOW которое зависит от часового пояса :) конечно значение в базе будет изменяться. данные в базе статичны и не зависит ни от чего. что положили, то и достанете. а вот КАК и что вы туда положите это уже другой вопрос
Правильно. Я записываю в таблицу время текущего часового пояса. И в DATETIME оно сохранится именно для этого пояса и точно также будет отображаться в дальнейшем, независимо от того, какой часовой пояс вы укажете. TIMESTAMP же покажет сохранённые данные по-разному для разный часовых поясов. Я где-то неправ?
> по усреднённому времени Гринвича
> Зависит от установленного часового пояса.
Время по Гринвичу для того и создавалось, чтобы не зависеть от часового пояса.
Тут понятие «зависимости» очень кривое…
В DATETIME «нулём» выбран локальный пояс, в TIMESTAMP — более универсальный UTC. Поэтому TIMESTAMP менее зависим от установленного часового пояса.
Определённые проблемы, кстати, вносит не только часовой пояс, но и летнее время…
> Зависит от установленного часового пояса.
Время по Гринвичу для того и создавалось, чтобы не зависеть от часового пояса.
Тут понятие «зависимости» очень кривое…
В DATETIME «нулём» выбран локальный пояс, в TIMESTAMP — более универсальный UTC. Поэтому TIMESTAMP менее зависим от установленного часового пояса.
Определённые проблемы, кстати, вносит не только часовой пояс, но и летнее время…
Добавил для вас пример без функции NOW().
А что насчет сравнения скорости выборки по полям типа Timestamp и DateTime? Например выборка по поределенному месяцу, дню недели и т д. В каком случае будет работать быстрее?
по таймстепу быстрее. Но если строить индекс по datetime, то рекомендуется использовать force index. Особенно это касается при выборке данных по указанным промежуткам времени.
А мне казалось что по dateTime многие выборки должны идти быстрее. Ведь логично, что например выборка по номеру месяца из записи вида YYYYMMDDHHMMSS должна осуществляться МНОГО быстрее, чем по записи вида timestamp. В случае c timestamp, как я понимаю, приходится каждое поле преобразовывать в дату и только потом производить операцию сравнения условия.
Еще полезная фича ON UPDATE CURRENT_TIMESTAMP, с datetime вроде не прокатит.
Было время намучался с етим CURRENT_TIMESTAMP и совсем запутался в часовых поясах, так как сервер был в штатах и имел необычную конфигурацию.
Как указать часовой пояс сервера в php все понятно, а вот с базой данных пришлось изощьрятся с помощью CONVERT_TZ, DATE_ADD, DATE_SUB так как доступа к конфигурации БД не предусматривалось.
Решил везде использовать DATETIME и дать возможность PHP самому указивать сколько времени.
Как указать часовой пояс сервера в php все понятно, а вот с базой данных пришлось изощьрятся с помощью CONVERT_TZ, DATE_ADD, DATE_SUB так как доступа к конфигурации БД не предусматривалось.
Решил везде использовать DATETIME и дать возможность PHP самому указивать сколько времени.
дату всегда храню в datetime.
во-первых читабельна
во-вторых есть куча удобных функций для работы с полем в формате datetime
ps. не знал что timestamp пересчитывается в соответствии с установленной временной зоной
во-первых читабельна
во-вторых есть куча удобных функций для работы с полем в формате datetime
ps. не знал что timestamp пересчитывается в соответствии с установленной временной зоной
UFO just landed and posted this here
не проще ли хранить таймстемп в обычном int?
Это отличный пример как не надо делать.
побольше слов, пожалуйста (если они есть)
Пока Nc_Soft молчит, позволю себе ответить за него.
Тип данных INT предназначен для хранения целых чисел.
Типы данных DATETIME и TIMESTAMP предназначены для… в общем, я уверен, что вы поняли, к чему я веду.
Так вот, давайте поставим вопрос с головы обратно на ноги: если у вас (не лично у вас, а у всех удивившихся) есть какие-то аргументы за то, чтобы использовать какой-либо тип данных не по его прямому назначению, игнорируя другой тип данных, предназначеный именно для решения вашей задачи — лично мне будет интересно их выслушать.
Тип данных INT предназначен для хранения целых чисел.
Типы данных DATETIME и TIMESTAMP предназначены для… в общем, я уверен, что вы поняли, к чему я веду.
Так вот, давайте поставим вопрос с головы обратно на ноги: если у вас (не лично у вас, а у всех удивившихся) есть какие-то аргументы за то, чтобы использовать какой-либо тип данных не по его прямому назначению, игнорируя другой тип данных, предназначеный именно для решения вашей задачи — лично мне будет интересно их выслушать.
Зря парня минусуете. Абсолютно правильно говорит. Хранить TIMESTAMP в INT это все-равно что в С (или паскале, или еще каком-нибудь языке программирования, кому как больше нравится) заводить переменную int вместо bool. Если в int сохранять 0 и 1, эффект будет абсолютно идентичный, но читабельность кода ухудшается. Ухудшается читабельность — увеличивается вероятность появления ошибки.
А почему INT? Давайте в VARCHAR или TEXT хранить дату, чего уж там…
Использовать для даты надо типы для даты, иначе вы потеряете кучу возможностей и простые операции, которые можно сделать в sql придется реализовывать уже средствами php.
Использовать для даты надо типы для даты, иначе вы потеряете кучу возможностей и простые операции, которые можно сделать в sql придется реализовывать уже средствами php.
По-моему проще сделать на php, чем заставлять делать это mysql.
Если у вас большой цикл, то проще сначала объявить переменную в php до цикла, а потом подставлять в запрос, чем каждый раз в запросе писать NOW()
Если у вас большой цикл, то проще сначала объявить переменную в php до цикла, а потом подставлять в запрос, чем каждый раз в запросе писать NOW()
Sql запросы в цикле лучше стараться не делать.
И вообще, не понимаю почему некоторые пытаются убедить, что забивать гвозди лопатой лучше, чем молотком.
Ну никакого преимущества нет у int по сравнению с timestamp в хранении даты.
Возьмем банальнейший пример: регистрация пользователя. Если тип int запрос будет какой-то такой
«INSERT INTO reg SET login='$login', pass=MD5('$pass'), reg_time='».time()."' "
Если поле reg_time имеет тип timestamp и по дефаулту у него стоит CURRENT_TIMESTAMP, то запрос будет уже такой
«INSERT INTO reg SET login='$login', pass=MD5('$pass') „
reg_time заполнится автоматически текущим временем.
Уже 1:0 в пользу timestamp :)
И вообще, не понимаю почему некоторые пытаются убедить, что забивать гвозди лопатой лучше, чем молотком.
Ну никакого преимущества нет у int по сравнению с timestamp в хранении даты.
Возьмем банальнейший пример: регистрация пользователя. Если тип int запрос будет какой-то такой
«INSERT INTO reg SET login='$login', pass=MD5('$pass'), reg_time='».time()."' "
Если поле reg_time имеет тип timestamp и по дефаулту у него стоит CURRENT_TIMESTAMP, то запрос будет уже такой
«INSERT INTO reg SET login='$login', pass=MD5('$pass') „
reg_time заполнится автоматически текущим временем.
Уже 1:0 в пользу timestamp :)
Про SQL запросы в цикле: если нужно сделать, значит нужно. Как вы предлагаете например вставить в таблицу 10000 записей?
А если мне нужно чтобы в поле reg_time был не текущий timestamp, а + один день?
$tomorrow = date('Y-m-d H:i:s', (time()+86400));
И на счёт MD5 не согласен. Лучше возложить это на php.
«INSERT INTO reg SET login='$login', pass='».md5($pass)."', reg_time='$tomorrow' "
А если мне нужно чтобы в поле reg_time был не текущий timestamp, а + один день?
$tomorrow = date('Y-m-d H:i:s', (time()+86400));
И на счёт MD5 не согласен. Лучше возложить это на php.
«INSERT INTO reg SET login='$login', pass='».md5($pass)."', reg_time='$tomorrow' "
>> Как вы предлагаете например вставить в таблицу 10000 записей?
Рекомендую так (примерно, я не знаю php):
Так не получится в одном случае — если вы вставляете достаточно большие значения и суммарный запрос превысит лимит размера запроса, установленный на сервере (по умолчанию 1Mb, если мне память не изменяет).
Делать 10000 инсертов в такой ситуации — это очень неоптимально.
>> А если мне нужно чтобы в поле reg_time был не текущий timestamp, а + один день?
У mysql полно функций, работающих с датами, практически всегда можно найти нужную под задачу.
>> И на счёт MD5 не согласен. Лучше возложить это на php.
Вы хоть какие то доводы привели бы. Почему лучше? Потому что лично вам так нравится больше? Или потому что вы просто возможности mysql знаете гораздо меньше, чем возможности php?
Рекомендую так (примерно, я не знаю php):
INSERT INTO table (col1,col2) VALUES
for ($i=1; $i<=10000; $i++)
{
(...тут значения столбцов...)
}[, ]Так не получится в одном случае — если вы вставляете достаточно большие значения и суммарный запрос превысит лимит размера запроса, установленный на сервере (по умолчанию 1Mb, если мне память не изменяет).
Делать 10000 инсертов в такой ситуации — это очень неоптимально.
>> А если мне нужно чтобы в поле reg_time был не текущий timestamp, а + один день?
У mysql полно функций, работающих с датами, практически всегда можно найти нужную под задачу.
>> И на счёт MD5 не согласен. Лучше возложить это на php.
Вы хоть какие то доводы привели бы. Почему лучше? Потому что лично вам так нравится больше? Или потому что вы просто возможности mysql знаете гораздо меньше, чем возможности php?
На счет первого: согласен можно сделать так.
На счет второго и третьего: как то мы вставляли данные в MySQL, но предварительно нужно было вычислить экспоненты, логарифмы и прочую нечесть и сделали сначала с помощью MySQL. Сервак начал жутко тормозить. Потом перенесли эти расчеты на php, и всё стало намного быстрее.
Например у нас mysql сервер выделенный, и он очень загружен, а php сервер достаточно свободный, поэтому в данном случае вычислять лучше на php. Он это сделает быстрее
На счет второго и третьего: как то мы вставляли данные в MySQL, но предварительно нужно было вычислить экспоненты, логарифмы и прочую нечесть и сделали сначала с помощью MySQL. Сервак начал жутко тормозить. Потом перенесли эти расчеты на php, и всё стало намного быстрее.
Например у нас mysql сервер выделенный, и он очень загружен, а php сервер достаточно свободный, поэтому в данном случае вычислять лучше на php. Он это сделает быстрее
INSERT INTO reg SET login='$login', pass=MD5('$pass'), reg_time=NOW() + INTERVAL 1 DAY
Про инсерт в 10000 записей опять же можно сделать дефаултное значение и даже NOW() писать не придется, а используя int вы не можете сделать дефаултное значение текущей метки времени, это уже булыжник в огороде.
Про инсерт в 10000 записей опять же можно сделать дефаултное значение и даже NOW() писать не придется, а используя int вы не можете сделать дефаултное значение текущей метки времени, это уже булыжник в огороде.
Как вставить 1000 записей в базу
Синтаксис оператора INSERT
INSERT [LOW_PRIORITY | DELAYED] [IGNORE]
[INTO] tbl_name [(col_name,...)]
VALUES (expression,...),(...),…
Обратите внимание на последнюю строчку.
Запросов в цикле — не должно быть.
Синтаксис оператора INSERT
INSERT [LOW_PRIORITY | DELAYED] [IGNORE]
[INTO] tbl_name [(col_name,...)]
VALUES (expression,...),(...),…
Обратите внимание на последнюю строчку.
Запросов в цикле — не должно быть.
Однажды один умный человек мне сказал.
— Нет смысла перекладывать обязаннсоти сервера БД на web сервер.
Во-первых ему и так работы хватает.
Во-вторых сервер бд заточен для подобных операций, он куда лцчше это сделает.
— Нет смысла перекладывать обязаннсоти сервера БД на web сервер.
Во-первых ему и так работы хватает.
Во-вторых сервер бд заточен для подобных операций, он куда лцчше это сделает.
int — удобно для портирования базы в другую СУБД, в которой может отсутствовать timestamp.
Дак можно, наверное, как-нибудь переконвертить тип поля перед портированием?
ALTER TABLE что-то там…
Или с timestamp не получится?
ALTER TABLE что-то там…
Или с timestamp не получится?
А часто ли происходит данная «портация данных»? Да и будет ли самой большой проблемой именно портация таймстампта?
Имхо жертвовать повседневной удобностью ради сохранения десяти минут при операции которая проводица достаточно долго, тягостно и проблематично и без этого — феерический бред.
Имхо жертвовать повседневной удобностью ради сохранения десяти минут при операции которая проводица достаточно долго, тягостно и проблематично и без этого — феерический бред.
То есть других резонов, кроме «так надо» нет?
А аргументы за то, чтоб делать через одно место есть?
Наличие встроенных функций для работы с timestamp?
Ок.
Мне нужно выбрать все записи, в котором поле lastLogin не старше 01-05-2009. Как будет выглядеть запрос в случае timestamp?
Мне нужно выбрать все записи, в котором поле lastLogin не старше 01-05-2009. Как будет выглядеть запрос в случае timestamp?
select * from tbl WHERE lastLogin < '01-05-2009'
Тоесть вот так конечно же
select * from tbl WHERE lastLogin < '2009-05-01'
select * from tbl WHERE lastLogin < '2009-05-01'
и оно будет работать быстрее, чем
select * from tbl WHERE lastLogin < 1241136000 (в случае инта)?
select * from tbl WHERE lastLogin < 1241136000 (в случае инта)?
Тут надо тесты проводить по хорошему. Я думаю, что запросы будут одинаковыми по скорости, если оптимизатор mysql просечет фишку и сконвертирует дату 2009-05-01 в число, а потом будет делать выборку на основе сравнения чисел.
А какая разница? У вас уже в конкретной задаче скорости не хватает? Мне кажется, решение с таймстампом лучше, потому что:
1. лучше читается.
2. удобнее в использовании.
Если начинает не хватать скорости, то переконвертить в инт действительно может быть одним из способов оптимизации (если быстрее, конечно).
1. лучше читается.
2. удобнее в использовании.
Если начинает не хватать скорости, то переконвертить в инт действительно может быть одним из способов оптимизации (если быстрее, конечно).
Вопрос на засыпку: вы уверены, что mysql переведет дату в число 1241136000 быстрее чем язык из которого вы формируете SQL-запрос?
ВИН.
ВИН.
select * from tbl WHERE lastLogin < Unix_timestamp('01-05-2009')
и оно будет работать быстрее, чем
select * from tbl WHERE lastLogin < 1241136000 (в случае инта)?
select * from tbl WHERE lastLogin < 1241136000 (в случае инта)?
Зачем здесь функция Unix_timestamp(), если поле типа timestamp? Этот запрос ничего не найдет вообще.
слева таймстемп — справа строка, приведенная к таймстемпу с помощью функции.
Почему вы считаете, что unix_timestamp и тип данных mysql timestamp — это одно и тоже? Это не так. TIMESTAMP — это специальный подвид типа DATETIME!!! Я ниже более подробно описал различия.
Если не верите мне, проверьте сами, ваш запрос не работает, потому что слева — дата, а справа число.
Если не верите мне, проверьте сами, ваш запрос не работает, потому что слева — дата, а справа число.
перед тем как мучать DB нужно ответить на вопрос «что такое „01-05-2009“»?
Знаю одну довольно известную вебдизайнерскую контору, где так и делают. :)
простые операции, которые можно сделать в sql придется реализовывать уже средствами php
яркий пример устоявшихся связей и шаблонности человеческого мышления. ведь кроме php есть куча других языков, но почти всегда вспоминают шаблон mysql+php :D
Как раз на днях столкнулся с реальным индусским кодом, где timestamp хранился в поле типа TEXT :)
ага, это почему это?
UFO just landed and posted this here
Есть достаточное количество удобных функций для работы с датами (http://dev.mysql.com/doc/refman/5.0/en/date-and-time-functions.html).
Например:
SELECT DATE_ADD(created_at, INTERVAL 1 MONTH) FROM…
С полем типа INT они работать не будут, с DATETIME/TIMESTAMP будут.
Кроме того обычный SELECT преобразует вам DATETIME/TIMESTAMP в читабельный вид.
Например:
SELECT DATE_ADD(created_at, INTERVAL 1 MONTH) FROM…
С полем типа INT они работать не будут, с DATETIME/TIMESTAMP будут.
Кроме того обычный SELECT преобразует вам DATETIME/TIMESTAMP в читабельный вид.
Храню дату в BIGINT потому как работаю с JAVA — а там дата фактически хранится в миллисекундах от определенного момента времени.
Проблем ни с индексами, ни с запросами не испытываю — потому как при запросах с WHERE < > дата с которой происходит сравнение автоматически конвертируетсяв BIGINT.
Функции DATE_ADD и прочие мне не нужны — потому как у меня апп-сервер и все происходит на нем. Учет клиентской таймзоны — тоже на апп-сервере.
На крайний случай, когда надо глазами в консоли посмотреть чего записано, использую FROM_UNIXTIME(date/1000)
Проблем ни с индексами, ни с запросами не испытываю — потому как при запросах с WHERE < > дата с которой происходит сравнение автоматически конвертируетсяв BIGINT.
Функции DATE_ADD и прочие мне не нужны — потому как у меня апп-сервер и все происходит на нем. Учет клиентской таймзоны — тоже на апп-сервере.
На крайний случай, когда надо глазами в консоли посмотреть чего записано, использую FROM_UNIXTIME(date/1000)
как было подмечено выше «timestamp выводится так же как и datetime в новых версиях mysql ('YYYY-MM-DD HH:MM:SS', точно в 5.0), в старых без пунктуации.»
т.е. к int-у это не сработает. а в остальном не вижу различий между int и timestamp
т.е. к int-у это не сработает. а в остальном не вижу различий между int и timestamp
то есть если мне надо банально узнать в похапе разницу в секундах между двумя таймстемпами, мне надо 'YYYY-MM-DD HH:MM:SS' конвертировать в int?
я говорил про timestamp vs int.
а ваш вопрос о другом.
но тем не менее.
как часто вам приходится работать с датами в виде целого числа?
не думаю что за еденичный запрос вам приходится делать тысячи конвертаций в int.
думаю плюсы datetime в виде функций ADDDATE,YEARWEEK,CONVERT_TZ… все таки перевешивают плюсы timestamp-а
а ваш вопрос о другом.
но тем не менее.
как часто вам приходится работать с датами в виде целого числа?
не думаю что за еденичный запрос вам приходится делать тысячи конвертаций в int.
думаю плюсы datetime в виде функций ADDDATE,YEARWEEK,CONVERT_TZ… все таки перевешивают плюсы timestamp-а
А как же ADDTIME(FROM_UNIXTIME(`unix_timestamp`))? :)
при таком варианте индекс не получится использовать. mysql-ю придется конвертить каждое значение для обработки запроса
Бррр… я окончательно запутался в том, кто про что пишет, потому в предыдущем комментарии написал вообще нечто, никак не связанное с вашими словами выше. Произвожу корректировку :)
Вы написали следующее (на что я вам ответил про вариант с int, что не к селу ни к городу)
>> думаю плюсы datetime в виде функций ADDDATE,YEARWEEK,CONVERT_TZ… все таки перевешивают плюсы timestamp-а
Ответ — неверно. TIMESTAMP — это тоже временной тип данных, поэтому все функции применимые к DATETIME применимы и к TIMESTAMP. Разница лишь в методе хранения этих типов — DATETIME хранится в виде числа! YYYYMMDDHHMMSS, а TIMESTAMP в виде количества секунд с Epoch. Не считая еще описанной в топике разницы с TZ, того, что timestamp не может быть null, и фич с автоапдейтом, с точки зрения программиста они одинаковы. Но внутренее хранение накладывает еще и свои различия — DT больше TS в два раза, зато позволяет записывать даты произвольные, а не с 70 по 38 год.
И всё таки про индексы тоже скажу. Раз вы про них упомянули, значит речь идет об использовании этих функций в WHERE (или join, что тоже самое). Скажите, почему вы решили, что например
не будет использовать индексы, а
— будет? Индекс не будет работать в обоих случаях
Вы написали следующее (на что я вам ответил про вариант с int, что не к селу ни к городу)
>> думаю плюсы datetime в виде функций ADDDATE,YEARWEEK,CONVERT_TZ… все таки перевешивают плюсы timestamp-а
Ответ — неверно. TIMESTAMP — это тоже временной тип данных, поэтому все функции применимые к DATETIME применимы и к TIMESTAMP. Разница лишь в методе хранения этих типов — DATETIME хранится в виде числа! YYYYMMDDHHMMSS, а TIMESTAMP в виде количества секунд с Epoch. Не считая еще описанной в топике разницы с TZ, того, что timestamp не может быть null, и фич с автоапдейтом, с точки зрения программиста они одинаковы. Но внутренее хранение накладывает еще и свои различия — DT больше TS в два раза, зато позволяет записывать даты произвольные, а не с 70 по 38 год.
И всё таки про индексы тоже скажу. Раз вы про них упомянули, значит речь идет об использовании этих функций в WHERE (или join, что тоже самое). Скажите, почему вы решили, что например
.... WHERE YEARWEEK(FROM_UNIXTIMESTAMP(`unixtime`)) = 200922 ... не будет использовать индексы, а
.... WHERE YEARWEEK(`datetime`) = 200922 ... — будет? Индекс не будет работать в обоих случаях
а я про них и спрашивал
вот у меня есть какое-нибудь событие, например пользователь входит в систему — login. я хочу сделать запись в базу о том, когда это случилось. функция time мне возвращает int. я его в неизменном виде отражаю в базе, как mysql int. когда мне нужно показать пользователю (или админу) дату его последнего захода, то я возьму этот int из базы и с помошью date преобразую и покажу в нужном формате — верно?
какие преимущества может дать мне в этом случае mysql timestamp?
вот у меня есть какое-нибудь событие, например пользователь входит в систему — login. я хочу сделать запись в базу о том, когда это случилось. функция time мне возвращает int. я его в неизменном виде отражаю в базе, как mysql int. когда мне нужно показать пользователю (или админу) дату его последнего захода, то я возьму этот int из базы и с помошью date преобразую и покажу в нужном формате — верно?
какие преимущества может дать мне в этом случае mysql timestamp?
> как часто вам приходится работать с датами в виде целого числа?
Мне с ними приходится работать каждый раз, когда в шаблоне надо cделать strftime… То есть, собственно, мне только в таком виде с датами и приходится работать, за реееедким исключением.
Мне с ними приходится работать каждый раз, когда в шаблоне надо cделать strftime… То есть, собственно, мне только в таком виде с датами и приходится работать, за реееедким исключением.
UFO just landed and posted this here
timestamp может обновляться сам при апдэйте данных (ON UPDATE CURRENT_TIMESTAMP) и такое поле может быть только одно в таблице
если TIMESTAMP полей несколько, автоматом обновляется, только, первое
при одном из условий:
Столбец не указан явно в команде INSERT или LOAD DATA INFILE.
Столбец не указан явно в команде UPDATE, и при этом изменяется величина в некотором другом столбце (следует отметить, что команда UPDATE, устанавливающая столбец в то же самое значение, которое было до выполнения команды, не вызовет обновления столбца TIMESTAMP, поскольку в целях повышения производительности MySQL игнорирует подобные обновления при установке столбца в его текущее значение).
Величина в столбце TIMESTAMP явно установлена в NULL.
Столбец не указан явно в команде UPDATE, и при этом изменяется величина в некотором другом столбце (следует отметить, что команда UPDATE, устанавливающая столбец в то же самое значение, которое было до выполнения команды, не вызовет обновления столбца TIMESTAMP, поскольку в целях повышения производительности MySQL игнорирует подобные обновления при установке столбца в его текущее значение).
Величина в столбце TIMESTAMP явно установлена в NULL.
Простите, но для пользователя PostgreSQL данный топик кажется дикостью.
я так понимаю, что TIMESTAMP в определенный момент даст сбой (так как 4х байтное число INT конечно)?
В 38-м году, если не ошибаюсь.
ru.wikipedia.org/wiki/Проблема_2038_года =) мы все умрем?
Есть мысть, не помню кем высказанная, что метки времени нужно хранить в виде timestamp. Ну к примеру когда пользователь залогинился, или метки для подсчета кол-ва пользователей на сайте.
Дату рождения же соит хранить в виде DateTime.
Мысть не моя. Насколько она верна — думайте сами.
Дату рождения же соит хранить в виде DateTime.
Мысть не моя. Насколько она верна — думайте сами.
Еще один прочитал маны… Давайте тогда будем писать статьи о том, чем в php echo от print отличается? Если разработчик не знает в чем разница между datetime и timestamp, то это не разработчик, а полуграмотный недоучка, которому лень было основные разделы документации прочитать.
Зря вы так. Покажите мне разработчиков, которые прочитали всю официальную документацию по MySQL. А я описал случай, с которым столкнулся на практике.
это вопрос все-же не про MySQL
это общий вопрос по информатике
поддерживаю Psoxozzz, не смотря на ник
недоразработчики — это зло и для клиентов, и для нормальных ребят
это общий вопрос по информатике
поддерживаю Psoxozzz, не смотря на ник
недоразработчики — это зло и для клиентов, и для нормальных ребят
Нет, не зря. Я не спорю, что вы столкнулись с этим на практике. К сожалению, в наше время много начинающих людей, которые, нахватавшись вершков, считают себя профессионалами. Я поясню категоричность своего предыдущего комментария. В любом проекте сложнее двухстраничного статичного сайта используется СУБД. Не важно, MySQL это будет или тот же PostgreSQL. При проектировании БД залогом избавления от 90% проблем в будущем — это грамотное использование типов данных, расстановка индексов, не говоря уже об осторожном обращении с тремя степенями нормализации. Если же «специалист» уже на подготовительном этапе не владеет инструментом с которым работает, то гнать таких надо в шею, пока не научатся.
И совершенно не обязательно читать всю документацию по СУБД. Я не считаю проблемой время от времени зарываться в маны и обсуждать с коллегами сложные моменты при работе с СУБД. Но, простите меня за категоричность, не знание основ ставит на человеке крест как на специалисте.
Если к вам пришел на работу математик, которые не знает таблицы умножения, но при этом оправдывает это тем, что всего знать нельзя — это шарлатан.
И совершенно не обязательно читать всю документацию по СУБД. Я не считаю проблемой время от времени зарываться в маны и обсуждать с коллегами сложные моменты при работе с СУБД. Но, простите меня за категоричность, не знание основ ставит на человеке крест как на специалисте.
Если к вам пришел на работу математик, которые не знает таблицы умножения, но при этом оправдывает это тем, что всего знать нельзя — это шарлатан.
Вы пишете, что таких спецов надо гнать в шею, а я дал им материал, и теперь ещё 50-100 человек знают немного больше. Может это подтолкнёт их с систематизированному изучению СУБД. И как сказано выше, «это общий вопрос по информатике».
Вы правы, разработчики должны знать, как устроены индексы, что такое B-tree, понимать почему в некоторых запросах индекс не используется и т.д. Но они этого не знают в подавляющем большинстве, а проекты есть и их надо делать.
Компании же редко занимаются повышение квалификации своих сотрудников, на универ надежды нет. Поэтому как можем, так и просвещаем… :)
Вы правы, разработчики должны знать, как устроены индексы, что такое B-tree, понимать почему в некоторых запросах индекс не используется и т.д. Но они этого не знают в подавляющем большинстве, а проекты есть и их надо делать.
Компании же редко занимаются повышение квалификации своих сотрудников, на универ надежды нет. Поэтому как можем, так и просвещаем… :)
храню в int.
а чтобы работали функции работы с датами, использую FROM_UNIXTIME(`int_timestamp`)
а чтобы работали функции работы с датами, использую FROM_UNIXTIME(`int_timestamp`)
«многие разработчики не знают...»
вы на самом деле считаете, что таких людей можно назвать разработчиками?
и вы как-то странно подменяете понятия:
это как же?? транспортировка сервера из Магадана в Москву запускает апдейт базы??
при выводе timestamp для разных часовых поясов строковое представление будет разным — вот что нужно было написать.
и вообще. для web приложений не вижу смысла импользовать тип данных, отличный от timestamp. даже если вам нужно на экране вывести просто дату, без времени, вы никогда не узнаете, какое именно число месяца писать, не зная точного времени.
вы на самом деле считаете, что таких людей можно назвать разработчиками?
и вы как-то странно подменяете понятия:
TIMESTAMP [...] Зависит от установленного часового пояса
это как же?? транспортировка сервера из Магадана в Москву запускает апдейт базы??
при выводе timestamp для разных часовых поясов строковое представление будет разным — вот что нужно было написать.
и вообще. для web приложений не вижу смысла импользовать тип данных, отличный от timestamp. даже если вам нужно на экране вывести просто дату, без времени, вы никогда не узнаете, какое именно число месяца писать, не зная точного времени.
Часовой пояс на сервере устанавливается не транспортированием сервера из Магадана в Москву :)
это была ирония.
если вы поменяете часовой пояс на сервере без транспортировки, то значение полей timestamp не поменяется.
если вы поменяете часовой пояс на сервере без транспортировки, то значение полей timestamp не поменяется.
Значение, которое хранится в базе не поменяется, измениться его отображение при SELECT.
так потому и нужно писать, что зависит ОТОБРАЖЕНИЕ а не значение
Так и написано:
>> Зависит от установленного часового пояса.… Эта зависимость проявляется при отображении значения поля.
>> Зависит от установленного часового пояса.… Эта зависимость проявляется при отображении значения поля.
вот что написано:
TIMESTAMP
Хранит 4-байтное целое число, равное количеству секунд, прошедших с полуночи 1 января 1970 года по усреднённому времени Гринвича (т.е. нулевой часовой пояс, точка отсчёта часовых поясов). Зависит от установленного часового пояса.
TIMESTAMP
Хранит 4-байтное целое число, равное количеству секунд, прошедших с полуночи 1 января 1970 года по усреднённому времени Гринвича (т.е. нулевой часовой пояс, точка отсчёта часовых поясов). Зависит от установленного часового пояса.
>> Зависит от установленного часового пояса.
Тип данных TIMESTAMP зависит от часового пояса. Дальше разъяснение, что эта зависимость проявляется в отображении данных в SELECT. Всё верно!
Спор бесполезный. И так все уже поняли что к чему.
Тип данных TIMESTAMP зависит от часового пояса. Дальше разъяснение, что эта зависимость проявляется в отображении данных в SELECT. Всё верно!
Спор бесполезный. И так все уже поняли что к чему.
надеюсь, что вы никогда не будете писат манов.
не надейтесь :)
Не сбивайте с толку народ, поправьте пожалуйста что TIMESTAMP от часового пояса не зависит.
Не важно какие часовые пояса настроены на серверах, в один момент времени значение TIMESTAMP для них будет одно и то же.
А то вы путаете значение TIMESTAMP с его «отображением с использованием преобразования с поправкой на timezone». Не айс…
Не важно какие часовые пояса настроены на серверах, в один момент времени значение TIMESTAMP для них будет одно и то же.
А то вы путаете значение TIMESTAMP с его «отображением с использованием преобразования с поправкой на timezone». Не айс…
UFO just landed and posted this here
Спасибо за обзор.
В поле какого типа лучше реализовать хранение времени в милисекундах?
datetime и timestamp тут вообще никак не подходят.
datetime и timestamp тут вообще никак не подходят.
Всегда использую DATETIME при селектах юзаю DATE_FORMAT(`somefield`, '%d.%m.%Y в %H:%i') as `when`
и никаких проблем
и никаких проблем
Вопрос на котором валится 90% собеседуемых программистов :)
Я в смятении, парни. Ну мало того, что некоторые в этой теме даже не знают чем временные типы данных отличаются друг от друга. Так еще и находятся те, кто минусуют комментарии и даже (о боже) срут в карму за попытки объяснить и разжевать им информацию. При этом ни на один мой коммент никто не удосужился ответить хоть что-нибудь внятное и объяснить мне в чем я не прав, видимо кроме как на «кнопоньку давить», более эти люди ничего не могут. Мне обычно глубоко насрать на это, но не в данном случае. Свинство какое-то.
а зачем вы пишите о NOW() в TIMESTAMP??
значение TIMESTAMP обновляется само при создании строки или при апдейте какого-то из полей.
то есть в поле TIMESTAMP у нас всегда будет время создания этой строки в базе или время её последнего редактирования.
ИМХО
а вот применение TIMESTAMP в иных вариантах — лично для меня не совсем удобно.
но это всего лишь дело вкуса.
значение TIMESTAMP обновляется само при создании строки или при апдейте какого-то из полей.
то есть в поле TIMESTAMP у нас всегда будет время создания этой строки в базе или время её последнего редактирования.
ИМХО
а вот применение TIMESTAMP в иных вариантах — лично для меня не совсем удобно.
но это всего лишь дело вкуса.
В закладки
Для тех, кто не особо понял, советую прочитать вот это: habrahabr.ru/blogs/mysql/69983/
Кто-нибудь скажите, а почему если TIMESTAMP это по сути юниксовое время (с 1970 года), то откуда MySQL берет значения '0000-00-00 00:00:00'.
Например вот выдержка из одной из моих таблиц:
first_seen timestamp DEFAULT '0000-00-00 00:00:00',
last_seen timestamp DEFAULT '0000-00-00 00:00:00',
И реально, SELECT дает значения '0000-00-00 00:00:00'.
Например вот выдержка из одной из моих таблиц:
first_seen timestamp DEFAULT '0000-00-00 00:00:00',
last_seen timestamp DEFAULT '0000-00-00 00:00:00',
И реально, SELECT дает значения '0000-00-00 00:00:00'.
Only those users with full accounts are able to leave comments. Log in, please.
Datetime или timestamp