- 1
- 2
- 3
- 4
- 5
- 6
- 7
$h_month = date("m");
$h_day = date("d");
$h_year = date("Y");
$h_hour = date("H");
$h_minute = date("i");
$history = mysql_query("insert into history values('','$h_month','$h_day','$h_year','$h_hour','$h_minute','$total_open','$beat','$wins','$tie','$can_change_up','$can_change_down','$cannot_win','$t_adjusted_gain','$t_adjusted_loss','$t_dollar_amount')");
Я тоже так раньше делал)))
судя по названию таблицы - это статистика по данным - а значит хранить дату в таком виде не только можно, но и нужно - а вот теперь подумайка, недоумник, какой запрос отработает быстрее:
или
ps задолбали ламеры....
да ты лошара))
а как нащщщщёт записей за последнюю неделю месяца, или фиксированный интервал дат(чч/мм/гггг ЧЧ:ММ:СС) и прочая??
кстати, а что бы изменилось в твоих рассуждениях, если бы таблица называлась transactions, orders, actors или students?
и нахрена ваще типы полей Date и Datestamp, если "вариаций множество", давайте ваще всё хранить в полях типа VARCHAR, нахрена проблемы ;)
ps задолбали тролли
https://dev.mysql.com/doc/refman/8.0/en/date-and-time-types.html
Но вместо TIMESTAMP иногда лучше хранить целого питуха.
Как всегда ламерье не умеет в собственные инструменты?
Кстати, кто-нибудь проверял?
Если это OLTP СУБД, то конечно она должна быть нормализованной, и покажите мне тот проект, где боттлнек будет в выборе года.
Если это OLAP, то ее можно денормализовать. Но даже там дату не нужно разбивать на отдельные поля.
Но vic это типичный анскиллябрнуый безвузный пыхомакак.
Он не владеет терминологией (я с трудом понял, что "статистика" это OLAP).
Он считает, что без всяких пруфов таблицу нужно денормализовать.
Ну и вот еще кукаречет https://govnokod.xyz/_696/#comment-4799
Не представляю, как искать, когда компоненты даты/времени в отдельных колонках.
Зачем решать через жопу?
да сам ты лошара)
этот способ позволяет сделать уникальный ключ на часы+минуты!
так что код совсем не говно если действительно нужны компоненты даты в базе
[quote=скор]а на `year` у нас наложен индекс[/quote]
Да уж, офиггено эффективный индекс. Хотя если проект на пару сотен лет хотябы расчитан.. почему бы и нет?
на дату индекс будет один единственный и максимально эффективный. А если держать индексы по всем компонентам даты это неоправдано увеличит объем базы а также сильно увеличит временный затраты на вставку, что в истории гораздо важнее чем затраты на выборку
охуенно эффективный индекс, невьебаться, по рейнджу - мозг активируй - я посмотрю сколько у тебя такая таблица будет архивироваться.
[quote]а как нащщщщёт записей за последнюю неделю месяца, или фиксированный интервал дат(чч/мм/гггг ЧЧ:ММ:СС) и прочая??[/quote]
а что мешает держать еще интовый таймстамп?
ps Заебали толькопослеуниверситетские лохи, которые кроме нормализированых баз ни о чем не знают - практикуй побольше - и системы станет быстрее.
сплошная болтовня, где аргументы, реальные тесты?
Я вижу только картину такого рода:
в таблице 'users' имеются поля 'created_at', 'updated_at', 'deleted_at', 'logged_at' - все даты в формате datetime. Значит по-пацански - это разбить их на 4*6=24 поля? Валяйте.
[quote=vic]а что мешает держать еще интовый таймстамп[/quote]
а чт мешает хранить только таймстамп?? (без этих 6 полей). Или дату в формате DATETIME. Опять же без этих 6 интовых полей. ну и, как правильно сказал cheef, фпирёд разбивать поля created_at etc на 6 интовых, и индексы не забудьте.
p.s. надоели годадвапослеуниверситетские люди, воображающие что знают всё. практикуйте побольше - код будет читабельнее и системы мастабируемее.
У каждого есть право написать свой неповторимый извратный код)
с использованием таймстемпа это будет выглядеть так
преимущества:
- занимает в разы меньше места в базе
- четабельность кода несомненна
- скорость тоже не страдает
- даные не зависят от формата даты выводимой на экран
- дата содержит шерокий спектор данные(например часовой пояс)
mysql_query("SELECT * FROM `history` WHERE `date` BETWEEN ".mktime(0,0,0,0,0,$year)." AND ".mktime(0,0,0,0,0,$year+1));
Читабельность кода еще больше увеличится.
забыл сказать об недостатках таймстемпа:
- только преобразовав таймстемп в человеческую дату можно узнать что в нем хранится
- таймстемп начинает отсчет от January 1 1970 00:00:00 GMT. для дат более реннего периуда необходимо использовать другой формат хранения данных