Доброго времени суток коллеги.

Хочу с вами посоветоваться вот по какому вопросу. Допустим такая ситуация - есть стандартный форум аля темы - сообщения.

Темы:



Сообщения:



И вот я хочу вывести список тем с указанием всяческой информации о нем, в том числе количества сообщений в нем. Я конечно могу поступить просто, сделав вложенный запрос аля



Однако, такая конструкция начинает прилично тормозить когда тем и постов в них много. А не дай бог я захочу еще по этому количеству постов отсортировать, тогда база будет сначала считать кол-во постов для ВСЕХ тем и лишь потом делать сортировку, выливается это в запросы длящиеся по 40 секунд уже при 1000 тем и сообщений.

Поэтому приходит в голову мысль держать число постов в теме непосредственно в таблице forum_topic. И вроде как это спасает, но возникает новая проблема...

Такой подход означает, что при КАЖДОМ добавлении и удалении поста мне нужно делать пересчет количества постов и обновлять соотв. колонку в таблице тем  forum_topic. У меня конечно есть ф-ция, удаляющая пост и я могу ее дополнить - вписать в нее пересчет, аналогично для добавления.

Вот хочется спросить - можно ли решить эту задачу более оптимально?

Я слышал про такую вещь как Триггеры в SQL и триггерные ф-ции. Что мол можно повесить прямо SQL-ную ф-цию пересчета постов, которая будет запускаться как только будет дана команда DELETE / INSERT для таблицы постов forum_post. Правда тут еще не очень понятно как группу передавать, для которой этот пересчет надо делать, ну это уже надо разбираться с этими триггерами... вот собрался, но все же хотел спросить может чего поумнее придумать можно?

Триггеры появились в MySQL начиная с 5ой версии. Почитать про них можно здесь или здесь. Они увеличивают производительность за счёт уменьшение информации, которое пересылается от PHP к MySQL.

Это сообщение отредактировал(а) HackMan - 28.8.2008, 11:40

HackMan, пасибо. Правда у меня PostgreSQL, ну да не думаю что шибко большая разница...

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

Это сообщение отредактировал(а) Dima 2015 - 28.8.2008, 11:40

Я не думаю что использование триггеров сильно увеличит производительность, но мне самому интересно почитать мнение шарящих в этом деле   Предложенный тобой второй вариант (с дополнительным полем) давно проверен временем и с успехом используется в крупных CMS и на крупных серверах.

Это сообщение отредактировал(а) HackMan - 28.8.2008, 11:43

HackMan, понимаешь какая штука. Тут вопрос даже не в производительности а в общем подходе к проектированию проекта.

Вот представим, что у меня удаление и добавление постов происходит в 10ти разных местах кода, и далеко не всегда используется 1 и та же ф-ция. Ну вот допустим... Скажем у админа может быть опция "удалить все отмеченные сообщения", это будет работать уже другая ф-ция, и к ней тоже надо будет приписать пересчет постов.

А потом я еще захочу добавить какую-то ф-цию удаления или добавления постов, и когда-нибудь я обязательно забуду дописать ф-цию пересчета в нужное место. А потом буду искать где же.. где же...

Поэтому меня интересует как в принципе к таким вещам правильно подходить, это могут быть вовсе и не темы-посты, а скажем группы-участики, а там уж мест где может измениться число участников до дури.

В этом плане триггеры - очень удобная вещь. Думаю, тебе будет интересен этот примерчик.

HackMan, ага, нашел его по поиску еще до того как эту тему создал, но все равно спасибо ))))

Логически получается, что триггер  удобный и в плане производительности и в проектировании.   

Dima 2015, Если напишете триггер, то желательно закопипастить его сюда.   
(самому интересно, думаю и другим тоже будет интересно)

bobik02, не вопрос. Вот ща у меня штук 10 вкладок с ФАКами по триггерам открыты, ща прочитаю, напишу.. получете, а пока ждем авторитетов, которые скажут что все нетак и не эдак 

категорически не понимаю.
почему вместо join'a и группировки выполняется подзапрос?
почему делается left, а не inner join на таблицу user? неужели могут быть темы без автора?
зачем триггеры там, где можно оптимизировать запрос? кроме того, при постраничном выводе, можно сразу отсортировать записи и выбрать необходимое количество, вместо подсчета количества сообщений для всех тем...

skyboy, вот в этом месте по-подробней можно плиз?

Касаемо left / inner - когда писал, еще не вполне понимал что пишу, скопировал со старых баз. Нет не может быть тем без автора, да и бох с ними.



Так вопрос в теме так и звучит - как сделать по-другому? Вот надо мне отсортировать темы по количеству сообщений, если в таблице нет специальной для этой колонки и вложенного селекта я не делаю, то как?

во-первых, в первом сообщении на сортировку намека нет.
во-вторых, зачем делать сортировку по количеству сообщений?

postgresql: join
postgresql: секция GROUP BY

skyboy, намек есть.

"А не дай бог я захочу еще по этому количеству постов отсортировать, тогда база будет сначала считать кол-во постов для ВСЕХ тем и лишь потом делать сортировку".

Я уже понял что нужно GROUP BY курить : ))) Курю... хотя все равно был бы признателен если бы явно показал кто как число постов заджойнить.

Вроде понял... чтото в этом духе:



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

Хех... все хорошо в вышеописанном способе, но вот не задача. А если мне нужно еще посчитать что-нибудь из той же таблицы? Ну например тоже число постов этого же топика, но у которых автор - я. И как тогда? Ведь 2 раза ДЖОЙН сделать нельзя, а куда приклеить условие?