вообщем пишу галерею. там на главной значит идет вывод фоток, выложенных юзерами. и под каждой фоткой написано Комментариев -число.
Таблица комментариев присутствует, где у каждого коммента присутствует ид фотки, к которой он относится.
Как проще всего вывести для каждой фотки число комментариев ?
Понятно, что для каждой фотки делать каунт комментов из таблицы - это не дело.
У меня есть мысль сделать поле в таблице фоток, назвать Количество комментов. И при добавлении комментария для этой фотки плюсовать туда +1. А при удалении соответственно -1.
Может есть еще какой-то вариант ?
Спустя 21 минута, 30 секунд (10.04.2011 - 19:28) neadekvat написал(а):
COUNT(*) as count
...
GROUP BY photo_id
где photo_id - это колонка, которая поясняет, к какой фотке оставлен коммент.
Кажется, так.
В count будет количество комментов к каждой фотке.
Один запрос, не страшно, я думаю.
...
GROUP BY photo_id
где photo_id - это колонка, которая поясняет, к какой фотке оставлен коммент.
Кажется, так.
В count будет количество комментов к каждой фотке.
Один запрос, не страшно, я думаю.
Спустя 10 минут, 18 секунд (10.04.2011 - 19:38) Krevedko написал(а):
SELECT `photo_id` , COUNT( * ) AS count
FROM `comments`
GROUP BY `photo_id`
типа такого ? ну в базе проверил, вроде считает
photo_id count
255 1
256 6
попробую прикрутить попозже. спасибо
FROM `comments`
GROUP BY `photo_id`
типа такого ? ну в базе проверил, вроде считает
photo_id count
255 1
256 6
попробую прикрутить попозже. спасибо
Спустя 2 часа, 56 минут, 37 секунд (10.04.2011 - 22:35) kirik написал(а):
| Цитата (Krevedko @ 10.04.2011 - 12:06) |
| У меня есть мысль сделать поле в таблице фоток, назвать Количество комментов. И при добавлении комментария для этой фотки плюсовать туда +1. А при удалении соответственно -1. |
Самый оптимальный вариант. Только лучше конечно запилить триггер на обновление таблицы комментов, чтобы повесить прибавление/вычитания на БД, и не думать потом "что я ещё забыл"
Спустя 14 часов, 54 минуты, 6 секунд (11.04.2011 - 13:29) Krevedko написал(а):
эмм..группировка медленнее ? я прикрутил группировку. вроде работает.
но сделаю как скажет ув. эксперт.
но сделаю как скажет ув. эксперт.
Спустя 14 минут, 16 секунд (11.04.2011 - 13:43) neadekvat написал(а):
| Цитата (Krevedko @ 11.04.2011 - 14:29) |
| но сделаю как скажет ув. эксперт. |
Ни вот что обычных смертных не ставят
| Цитата (kirik @ 10.04.2011 - 23:35) |
| чтобы повесить прибавление/вычитания на БД, и не думать потом "что я ещё забыл" |
+1 самое геморрное.
Спустя 16 минут, 34 секунды (11.04.2011 - 14:00) Krevedko написал(а):
ну видимо если комментов будет по сто тыщ, запрос будет весьма тяжелым. хоть он и один
Спустя 37 минут, 45 секунд (11.04.2011 - 14:37) neadekvat написал(а):
| Цитата (Krevedko @ 11.04.2011 - 15:00) |
| ну видимо если комментов будет по сто тыщ |
Я не уверен, в каком случаи он будет тормозить больше: когда много комментов или когда много фоток.
Но вариант, когда постоянно подсчеты вести не надо, конечно, быстрее.
Спустя 18 минут, 56 секунд (11.04.2011 - 14:56) Krevedko написал(а):
а при чем тут много фоток ?
фоток выводится на страницу лимитированно. скажем 30 штук. из базы окромя адреса фотки, ее названия итд будет доставаться количество комментов к ней..и это из той же таблицы, т.е. тем же запросом. т.е. в этом месте никакого падения производительности не будет совершенно. единственное-добавиться запрос при добавлении/удалении коммента, но там один лишь небольшой UPDATE +1/-1
фоток выводится на страницу лимитированно. скажем 30 штук. из базы окромя адреса фотки, ее названия итд будет доставаться количество комментов к ней..и это из той же таблицы, т.е. тем же запросом. т.е. в этом месте никакого падения производительности не будет совершенно. единственное-добавиться запрос при добавлении/удалении коммента, но там один лишь небольшой UPDATE +1/-1
Спустя 6 часов, 50 минут, 29 секунд (11.04.2011 - 21:47) kirik написал(а):
| Цитата (neadekvat @ 11.04.2011 - 06:43) |
| Ни вот что обычных смертных не ставят |
Тут не столько дело в количестве фоток/комментов (хотя и в этом тоже), сколько в количестве запросов к БД.
Запросов SELECT (просмотр фоток) у нас будет гораздо больше чем INSERT/UPDATE (добавление коммента). Вариант хранения количества в той же таблице в любом случае выйгрышный, даже если не юзать триггер
Спустя 19 часов, 40 минут, 27 секунд (12.04.2011 - 17:27) Krevedko написал(а):
а вот скажите. я когда учился, нам рекомендовали стараться как можно сильнее резать таблицу на несколько...
сильно ли проседает производительность селекта с джойнами по сравниению с обычным селектомЮ когда все берется из одной таблицы ?
сильно ли проседает производительность селекта с джойнами по сравниению с обычным селектомЮ когда все берется из одной таблицы ?
Спустя 8 минут, 6 секунд (12.04.2011 - 17:35) waldicom написал(а):
выборка из одной таблицы априори быстрее выборки из нескольких таблиц. Но если JOIN идет по полям, на которые есть индексы, то и он будет выполняться быстро.
Спустя 2 часа, 25 минут, 24 секунды (12.04.2011 - 20:01) twin написал(а):
Не согласен я с таким утверждением.
Ибо скорость скорости - рознь. На больших нагрузках несколько раздельных запросов (если все построено правильно) гораздо предпчтительнее, чем JOIN.
Ибо отработать простой запрос, получить результат, обработать на стороне PHP и отработать второй очень часто гораздо выгоднее, чем залочить таблицу даже на время, на порядок меньшее, чем вся тразакция.
Тут все зависит от условий, в корорых приходится работть скрипту.
Так что как посмотреть и спроектировать. Может и из нескольких таблиц последовательными запросами брть данные выгоднее, чем из одной, а тем более сводной.
Ибо скорость скорости - рознь. На больших нагрузках несколько раздельных запросов (если все построено правильно) гораздо предпчтительнее, чем JOIN.
Ибо отработать простой запрос, получить результат, обработать на стороне PHP и отработать второй очень часто гораздо выгоднее, чем залочить таблицу даже на время, на порядок меньшее, чем вся тразакция.
Тут все зависит от условий, в корорых приходится работть скрипту.
Так что как посмотреть и спроектировать. Может и из нескольких таблиц последовательными запросами брть данные выгоднее, чем из одной, а тем более сводной.
Спустя 2 часа, 49 минут, 5 секунд (12.04.2011 - 22:50) kirik написал(а):
| Цитата (twin @ 12.04.2011 - 13:01) |
| На больших нагрузках несколько раздельных запросов (если все построено правильно) гораздо предпчтительнее, чем JOIN. |
Могу подтвердить эти слова. Когда проект разрастается, даже JOIN таблицы фоток и юзеров становится "тяжелым". Тогда все эти принципы нормализации СУБД идут ф топку и приходит деструктивная денормализация
Можно делать выводы - всё что удобно, то ресурсозатратно
Первый пункт - ORDER BY RAND, второй - JOIN, третий - СУБД в целом 