Форум PHP программистов > timestamp ниже 70 года

linker

31.01.2014 - 14:56

zelenin
Ага, что собственно сразу отменяет ответ о возможности хранить UNIX TIMESTAMP в полях типа INT. Потому что, если сейчас не надо делать такую статистическую выборку, то не факт, что потом не понадобится, а перехерачивать структуру таблицы из INT в нормальный DATETIME вкупе с полным рефакторингом код - это жесть величайшая. Поэтому умные люди говорят вам храните даты так, как положено, либо в DATETIME либо в TIMESTAMP. А вы рогами упёрлись.

_____________
Gear Framework
Gear Framework на Github

zelenin

31.01.2014 - 15:00

Цитата (linker @ 31.01.2014 - 13:56)

zelenin
Ага, что собственно сразу отменяет ответ о возможности хранить UNIX TIMESTAMP в полях типа INT. Потому что, если сейчас не надо делать такую статистическую выборку, то не факт, что потом не понадобится, а перехерачивать структуру таблицы из INT в нормальный DATETIME вкупе с полным рефакторингом код - это жесть величайшая. Поэтому умные люди говорят вам храните даты так, как положено, либо в DATETIME либо в TIMESTAMP. А вы рогами упёрлись.

вопрос топикстартера был о другом.

bestxp

31.01.2014 - 15:04

Цитата (zelenin @ 31.01.2014 - 15:00)

вопрос топикстартера был о другом.

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

linker

31.01.2014 - 15:05

zelenin
Здесь на форуме не только дают ответы на вопросы, но ещё при этом советуют как лучше. Если ТС спрашивает о заведомо ложном решении, естественно, что развитие темы может уйти в сторону от первоначального вопроса.

_____________
Gear Framework
Gear Framework на Github

zelenin

31.01.2014 - 15:07

Цитата (linker @ 31.01.2014 - 14:05)

zelenin
Здесь на форуме не только дают ответы на вопросы, но ещё при этом советуют как лучше. Если ТС спрашивает о заведомо ложном решении, естественно, что развитие темы может уйти в сторону от первоначального вопроса.

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

killer8080

31.01.2014 - 15:11

Цитата (zelenin @ 31.01.2014 - 13:07)

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

ответом было - правильно выбирать тип данных. Исторические даты нужно хранить в DATE, и даже не в DATTIME. Потому что дата атомарна сама по себе. Хранение в TIMESTAMP может привести к недоразумениям, как например влияние текущей временной зоны на дату рождения.

zelenin

31.01.2014 - 15:15

Цитата (killer8080 @ 31.01.2014 - 14:11)

Цитата (zelenin @ 31.01.2014 - 13:07)

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

ответом было - правильно выбирать тип данных. Исторические даты нужно хранить в DATE, и даже не в DATTIME. Потому что дата атомарна сама по себе. Хранение в TIMESTAMP может привести к недоразумениям, как например влияние текущей временной зоны на дату рождения.

согласен

linker

31.01.2014 - 15:19

Цитата (zelenin @ 31.01.2014 - 14:07)

Цитата (linker @ 31.01.2014 - 14:05)

zelenin
Здесь на форуме не только дают ответы на вопросы, но ещё при этом советуют как лучше. Если ТС спрашивает о заведомо ложном решении, естественно, что развитие темы может уйти в сторону от первоначального вопроса.

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

Невозможно в типе поля TIMESTAMP, но возможно в типе поля INT, НО какое отношение тип INT имеет к датам вообще, в то время когда существуют типы DATE, TIME, DATETIME, TIMESTAMP, YEAR? Видимо весь этот мусор придумали лишь для того, чтобы лишить программистов возможности хранить даты в INT, но пришли вы и раскрыли мировой заговор.

_____________
Gear Framework
Gear Framework на Github

Valick

31.01.2014 - 15:21

Цитата

ответом на вопрос было то, что это невозможно, хотя на самом деле это совершенно не так.

вы заблуждаетесь, в БД вы храните не дату, а число, тупо простое число, то что вы там себе подразумеваете в "бизнес-логике"... БД, мягко говоря, "не колышет".

_____________
Стимулятор ~yoomoney - 41001303250491

phpшник

31.01.2014 - 16:13

Цитата

вы заблуждаетесь, в БД вы храните не дату, а число, тупо простое число, то что вы там себе подразумеваете в "бизнес-логике"... БД, мягко говоря, "не колышет".

Вот именно БД неколышет то что я там храню, если я сохраняю дату в date, то БД будет знать "ага здесь дата". а дата это что по вашему? точно также набор символов в определенном порядке. Вот вы мне покажите алгоритм вычисления возраста юзера на PHP? то есть я дергаю 10 новых юзеров из БД, и вычисляю сколько им лет? конечно я могу также делать и при date() в паре strtotime(). но быстрее работает при готовом timestamp это делается в одну строчку.

Цитата

Ага, что собственно сразу отменяет ответ о возможности хранить UNIX TIMESTAMP в полях типа INT. Потому что, если сейчас не надо делать такую статистическую выборку, то не факт, что потом не понадобится, а перехерачивать структуру таблицы из INT в нормальный DATETIME вкупе с полным рефакторингом код - это жесть величайшая. Поэтому умные люди говорят вам храните даты так, как положено, либо в DATETIME либо в TIMESTAMP. А вы рогами упёрлись.

что мне мешает просто иметь поле date в традиционном виде? ведь дополнительное поле int не сильно утяжелит БД ? зато вычисления php существенно ускорится при больших нагрузках.

bestxp

31.01.2014 - 16:28

Цитата (phpшник @ 31.01.2014 - 16:13)

что мне мешает просто иметь поле date в традиционном виде? ведь дополнительное поле int не сильно утяжелит БД ? зато вычисления php существенно ускорится при больших нагрузках.

еще как увеличит нагрузку, если можно посчитать эту мелочь на уровне бд, то её там и стоит посчитать, ей это быстрее сделать, чем это будет делать интерпретатор, и чем сложнее логика тем больше лишнего будет на php, притом на DATE ты можешь повесить индексы

export(year from date_field) и все, и просчет года будет вообще пару долей секунды, точнее сказать уже чуть ли не посчитанным храниться xD
так что не стоит недооценивать мощь SQL баз

Valick

31.01.2014 - 16:28

Цитата

если я сохраняю дату в date, то БД будет знать "ага здесь дата"

не только знать, но и работать с этой датой на уровне СУРБД и "вычисления php" в этом случае вообще не нужны

_____________
Стимулятор ~yoomoney - 41001303250491

phpшник

31.01.2014 - 16:45

Цитата

еще как увеличит нагрузку, если можно посчитать эту мелочь на уровне бд, то её там и стоит посчитать, ей это быстрее сделать, чем это будет делать интерпретатор, и чем сложнее логика тем больше лишнего будет на php, притом на DATE ты можешь повесить индексы

export(year from date_field) и все, и просчет года будет вообще пару долей секунды, точнее сказать уже чуть ли не посчитанным храниться xD
так что не стоит недооценивать мощь SQL баз

Цитата

не только знать, но и работать с этой датой на уровне СУРБД и "вычисления php" в этом случае вообще не нужны

Нет вы меня не поняли, мне надо например вывести 10 новых юзеров из бд и в тоже время вычислить сколь кому лет, это что получается что это может сделать только MSQl? а какой транслятор будет высчитывать сколь кому лет? и при индексации база потолстеет.

мне именно timistamp для этого и нужен.

linker

31.01.2014 - 16:48

phpшник

Цитата

мне надо например вывести 10 новых юзеров из бд и в тоже время вычислить сколь кому лет

Блин, это замечательно делает MySQL, причём который сделает это быстрее, чем PHP.

Цитата

и при индексации база потолстеет.

База при этом не толстеет, при это увеличивается скорость выборки, если индексы правильно расставлены.

_____________
Gear Framework
Gear Framework на Github

Michael

31.01.2014 - 16:49

phpшник, все очень просто.

Если используешь фреймворк или цмс, в которых используются обертки над уровнем доступа к БД, и код которых предполагается должен работать с разными БД - mysql или postgreSql, то храни как число. Тут так делать - обычный случай, т.к. работа с этим числом будет одинакова для разных СУБД. Ориентироваться на особенности каких то специфичніх типов данных конкретной СУБД тут не принято (да и не выйдет). Пример тут - Drupal, yii.

Если же у тебя самопис какой то, свой движек под какую то одну СУБД, то используй ее удобные типы. Пример тут - Wordpress, opencart.

_____________
There never was a struggle in the soul of a good man that was not hard