Говнокод #696 — PHP — Говнокод.ру

PHP / Говнокод #696

+173.1
1. 1
2. 2
3. 3
4. 4
5. 5
6. 6
7. 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')");
```
вот так вот человек хранит дату в БД =)

Запостил: guest, 12 Марта 2009

Tweet
Комментарии (23) RSS
- guest 13.03.2009 21:33 # 0
  
  skor:
  Я тоже так раньше делал)))
  Ответить
- guest 14.03.2009 18:08 # +1
  vic:
  судя по названию таблицы - это статистика по данным - а значит хранить дату в таком виде не только можно, но и нужно - а вот теперь подумайка, недоумник, какой запрос отработает быстрее:
  
  SELECT * FROM `history` WHERE `year`=2008; -- а на `year` у нас наложен индекс
  
  или
  
  SELECT * FROM `history` WHERE `date` BETWEEN .... ; -- это если дата в таймштампе, или извлечение года из него, или если в дататайме - вариаций множество...
  
  ps задолбали ламеры....
  Ответить
- guest 16.03.2009 13:13 # +2
  
  недоТролль:
  да ты лошара))
  
  а как нащщщщёт записей за последнюю неделю месяца, или фиксированный интервал дат(чч/мм/гггг ЧЧ:ММ:СС) и прочая??
  
  кстати, а что бы изменилось в твоих рассуждениях, если бы таблица называлась transactions, orders, actors или students?
  
  и нахрена ваще типы полей Date и Datestamp, если "вариаций множество", давайте ваще всё хранить в полях типа VARCHAR, нахрена проблемы ;)
  
  ps задолбали тролли
  Ответить
  - guest6 25.08.2023 00:59 # +1
    
    в нормальных субд есть спец типы для дат, но богом обиженные пыхеры и мусульщики об этом даже не догадываются
    Ответить
    - ropuJIJIa 25.08.2023 01:07 # 0
      
      Держи, их дофига:
      https://dev.mysql.com/doc/refman/8.0/en/date-and-time-types.html
      
      Но вместо TIMESTAMP иногда лучше хранить целого питуха.
      Ответить
      
      guest6 25.08.2023 01:09 # +1
      
      о чём тогда дебилы спорят?
      
      Как всегда ламерье не умеет в собственные инструменты?
      Ответить
      
      ropuJIJIa 25.08.2023 01:15 # 0
      
      Смотри выше комментарий со словом BETWEEN. Тот гость считает, что выборка по году отработает быстрее, если год будет в отдельной колонке, а не в ячейке типа DATETIME.
      
      Кстати, кто-нибудь проверял?
      Ответить
      
      guest6 25.08.2023 01:22 # 0
      
      Это где " это статистика по данным "?
      
      Если это OLTP СУБД, то конечно она должна быть нормализованной, и покажите мне тот проект, где боттлнек будет в выборе года.
      
      Если это OLAP, то ее можно денормализовать. Но даже там дату не нужно разбивать на отдельные поля.
      
      Но vic это типичный анскиллябрнуый безвузный пыхомакак.
      
      Он не владеет терминологией (я с трудом понял, что "статистика" это OLAP).
      Он считает, что без всяких пруфов таблицу нужно денормализовать.
      Ну и вот еще кукаречет https://govnokod.xyz/_696/#comment-4799
      Ответить
      
      ropuJIJIa 25.08.2023 01:21 # 0
      
      Если что, я за DATETIME, потому что этот тип позволит выбрать записи за определённый временной промежуток штатным способом.
      
      Не представляю, как искать, когда компоненты даты/времени в отдельных колонках.
      Ответить
      
      guest6 25.08.2023 01:23 # +1
      
      а еще она наверное поддерживает високосные годы. А еще она не поддерживает 32е число 22го месяца, а это говнорешение поддерживает.
      
      Зачем решать через жопу?
      Ответить
- guest 16.03.2009 14:08 # −1
  
  E:
  да сам ты лошара)
  этот способ позволяет сделать уникальный ключ на часы+минуты!
  так что код совсем не говно если действительно нужны компоненты даты в базе
  Ответить
- guest 16.03.2009 15:08 # +2
  
  Проходивший:
  [quote=скор]а на `year` у нас наложен индекс[/quote]
  
  Да уж, офиггено эффективный индекс. Хотя если проект на пару сотен лет хотябы расчитан.. почему бы и нет?
  
  на дату индекс будет один единственный и максимально эффективный. А если держать индексы по всем компонентам даты это неоправдано увеличит объем базы а также сильно увеличит временный затраты на вставку, что в истории гораздо важнее чем затраты на выборку
  Ответить
- guest 17.03.2009 10:57 # −3
  
  [quote]на дату индекс будет один единственный и максимально эффективный.[/quote]
  охуенно эффективный индекс, невьебаться, по рейнджу - мозг активируй - я посмотрю сколько у тебя такая таблица будет архивироваться.
  Ответить
- guest 17.03.2009 11:00 # −2
  
  vic:
  [quote]а как нащщщщёт записей за последнюю неделю месяца, или фиксированный интервал дат(чч/мм/гггг ЧЧ:ММ:СС) и прочая??[/quote]
  
  а что мешает держать еще интовый таймстамп?
  
  ps Заебали толькопослеуниверситетские лохи, которые кроме нормализированых баз ни о чем не знают - практикуй побольше - и системы станет быстрее.
  Ответить
- guest 17.03.2009 14:42 # +5
  
  cheef:
  сплошная болтовня, где аргументы, реальные тесты?
  
  Я вижу только картину такого рода:
  в таблице 'users' имеются поля 'created_at', 'updated_at', 'deleted_at', 'logged_at' - все даты в формате datetime. Значит по-пацански - это разбить их на 4*6=24 поля? Валяйте.
  Ответить
- guest 18.03.2009 22:43 # +3
  
  недоТролль:
  [quote=vic]а что мешает держать еще интовый таймстамп[/quote]
  
  а чт мешает хранить только таймстамп?? (без этих 6 полей). Или дату в формате DATETIME. Опять же без этих 6 интовых полей. ну и, как правильно сказал cheef, фпирёд разбивать поля created_at etc на 6 интовых, и индексы не забудьте.
  
  p.s. надоели годадвапослеуниверситетские люди, воображающие что знают всё. практикуйте побольше - код будет читабельнее и системы мастабируемее.
  Ответить
- guest 19.03.2009 15:18 # +1
  
  xm:
  У каждого есть право написать свой неповторимый извратный код)
  Ответить
- guest 26.03.2009 19:57 # 0
  date() отменили?
  Ответить
- guest 24.04.2009 01:50 # 0
  
  date() тут как раз и используется. много раз)
  Ответить
- guest 29.07.2009 14:49 # 0
  dead_star:
  с использованием таймстемпа это будет выглядеть так
  
  $year = 2008; mysql_query("SELECT * FROM `history` WHERE `date` > ".mktime(0,0,0,0,0,$year)." AND date` < ".mktime(0,0,0,0,0,$year+1));
  
  преимущества:
  - занимает в разы меньше места в базе
  - четабельность кода несомненна
  - скорость тоже не страдает
  - даные не зависят от формата даты выводимой на экран
  - дата содержит шерокий спектор данные(например часовой пояс)
  Ответить
  - guest 08.09.2009 16:05 # 0
    
    Небольшой совет, используй BETWEEN. Т.е.
    mysql_query("SELECT * FROM `history` WHERE `date` BETWEEN ".mktime(0,0,0,0,0,$year)." AND ".mktime(0,0,0,0,0,$year+1));
    
    Читабельность кода еще больше увеличится.
    Ответить
- guest 29.07.2009 14:55 # 0
  
  dead_star:
  забыл сказать об недостатках таймстемпа:
  - только преобразовав таймстемп в человеческую дату можно узнать что в нем хранится
  - таймстемп начинает отсчет от January 1 1970 00:00:00 GMT. для дат более реннего периуда необходимо использовать другой формат хранения данных
  Ответить
  - guest 08.09.2009 16:02 # 0
    
    Ээээ, они какбэ отрицательными делаются. Т.е. если дату рождения надо хранить, то поле НЕ ставится unsigned.
    Ответить
Добавить комментарий
Ошибка компиляции комментария:

Гости могут высказаться только в понедельник, среду, четверг или воскресение
Я, guest, находясь в здравом уме и твердой памяти, торжественно заявляю:

А не использовать ли нам bbcode?

[b]жирный[/b] — жирный

[i]курсив[/i] — курсив

[u]подчеркнутый[/u] — подчеркнутый

[s]перечеркнутый[/s] — перечеркнутый

[blink]мигающий[/blink] — мигающий

[color=red]цвет[/color] — цвет (подробнее)

[size=20]размер[/size] — размер (подробнее)

[code=<language>]some code[/code] (подробнее)

Проверочный код: *

Говнокод: по колено в коде.

PHP / Говнокод #696

Комментарии (23) RSS

Добавить комментарий