Индекс по datetime или хранить в отдельном поле date и пользоваться индексом по ней

[FB3]

Индекс по datetime или хранить в отдельном поле date и пользоваться индексом по ней

Простой пример: храним в таблице какие-то события с датой и временем, когда событие произошло. Потребовалось нам построить график, отображающий, сколько событий произошло в определенный день.

Будет ли принципиально большая разница в производительности между двумя нижеследующими вариантами на большой таблице, если не требуется выполнять запрос часто.
Варианты такие:
храним только datetime и индекс по ней, в запросе делаем ... COUNT(*) ... GROUP BY DATE(`datetime`)
храним datetime и date + индекс по date, в запросе делаем ... COUNT(*) ... GROUP BY `date`

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

 

[dimagolov]

FB3, для тебе слово "денормализация" неизвестно? сделай триггеры для синхронизации date по datetime, чтобы гарантировать целостность. очевидно ведь, что DATE(`datetime`) индекс использовать не будет.

 

[Mols]

FB3
Я где-то слышал о том, что некоторые используют совершенно варварский способ типа "Сделать запрос и посмотреть время выполнения"

 

[FB3]

dimagolov
Для меня известно это слово, я пока что делал по первому варианту. Вроде пока нареканий нет, видимо потому, что запрос действительно не критичный.
Но товарищ в похожей ситуации сделал по второму варианту, который мне не понравился. Целостность там по идее не должна пострадать, потому что при вставке строк используется функция NOW() для обоих полей. Хотя теоретически есть вероятность, что раз функция дважды вызывается, то может разные результаты вернуть.
А с триггером вариант, что будем вставлять одно поле, а по триггеру будет автоматически ставляться дата из datetime во второе поле date, правильно я понимаю? Тогда че-то не понимаю, где здесь нормализация... Ааа, можно ведь по триггеру пересчитывать и апдейтить поле в другой табличке, где уже сумма COUNT(*) на каждую дату хранится, да? Фактически, тогда одна запись весь день в этой табличке будет апдейтиться. Вот этот вариант интереснее, подумаю.

Mols
да нету у меня сейчас большой такой таблички, чтобы "Сделать запрос и посмотреть время выполнения". На не очень большой табличке (20-50к записей) разница была не критичная. Меньше секунды было в обоих случаях. Так как это не высоконагруженный запрос, для внутреннего пользования, то и 0.5 секунды - нормально.

 

[С.]

Так как это не высоконагруженный запрос, для внутреннего пользования, то и 0.5 секунды - нормально.

И зачем тогда копулировать мозги себе и окружающим?

 

[FB3]

Хочется понять, как делать нормально. К тому же, табличка будет расти наверняка, так что если вырастет до 10-20 секунд, то наверняка надо будет переделать.

 

[С.]

Ну как вырастет до 10-20 секунд, и если к тому времени понимание, как делать правильно не придет само, то милости просим, обсудим.

 

[FB3]

С.
Ну я хочу уже в следующий раз нормально сделать или даже переделать в ближайшее время, если время будет, а не тогда, когда тормозить начнет.

 

[dimagolov]

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

 

[FB3]

dimagolov
ну это я и так понимаю.
Вопрос был все таки в том, как нормально сделать и я понял, как нужно сделать (отдельную табличку, где хранить сумму).

 

[prolis]

Автор оригинала: FB3
я понял, как нужно сделать (отдельную табличку, где хранить сумму).

Суть комментариев была всё-таки в другом: когда действительно понадобится - будешь хранить агрегаты отдельно, а пока преждевременная оптимизация вредна (да ещё и триггерами).