Форум MySQL

>Что за кэширующая таблица? Первый раз слышу. Как ее создавать?
Это обычная таблица, пусть вам нужно связать пользователей и их статьи, создаете таблицу, где пользователям соответствуют их статьи

id_user - articles 45 - 2, 8, 10, 15, 17, 22 46 - 1, 9, 11, 18, 36 47 - 4, 12, 23, 37

Как только пользователь добавляет или удаляет статью, вы уничтожаете для него запись в этой таблице и расчитываете её по новой. Потребовались вас статьи пользователя 46, разбросанные по множеству разделов, вместо того чтобы строить многоэтажные запросы вы извлекаете запись из этой таблице (благодаря индексированию это будет очень быстро) и формируете запрос

SELECT * FROM tbl WEHRE id_article IN (1, 9, 11, 18, 36)

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

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

Как их лучше будет проиндексировать, в таком случае?

> вы же всегда можете создать кэширующую таблицу

Что за кэширующая таблица? Первый раз слышу. Как ее создавать?

Как проиндексируете...

PS А вообще если будет медленно, вы же всегда можете создать кэширующую таблицу, со связями консультатн - список всех его статей и сопутствующей информации. Да, это потребует определенных телодвижений на стадии добавления и редактирования, но снизит нагрузку по выборке из базы данных. Если есть место на диске, терпение и время, любую базу данных можно обуздать.

Еще, по задаче нужно сделать связку статей и пользователей. Т.е. на определенных субодменах (которые принадлежат консультантам) выводить статьи только этих консультантов.

Четырехтабличный запрос (если к этому запросу еще прибавить связку пользователей) это будет вообще жесть? Или нормально?

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

Спасибо!

Это будет быстрей чем кореллированный запрос?

Спасибо!

Это будет быстрей чем кореллированный запрос?

Это в поле labels? Используйте ключевое слово DISTINCT

SELECT      articles.id_article,      articles.id_group,      articles.title,      articles.showhide,      articles.datetime_add,      articles_labels.label,      GROUP_CONCAT(DISTINCT labels.label) AS labels  FROM articles      LEFT JOIN articles_labels ON articles_labels.id_article = articles.id_article      LEFT JOIN articles_labels AS labels ON labels.id_article = articles.id_article  GROUP BY articles.id_article  ORDER BY datetime_add DESC  LIMIT 0, 15

Добавил еще одну таблицу, так:

SELECT     articles.id_article,     articles.id_group,     articles.title,     articles.showhide,     articles.datetime_add,     articles_labels.label,     GROUP_CONCAT(labels.label) AS labels FROM articles     LEFT JOIN articles_labels ON articles_labels.id_article = articles.id_article     LEFT JOIN articles_labels AS labels ON labels.id_article = articles.id_article GROUP BY articles.id_article ORDER BY datetime_add DESC LIMIT 0, 15

Но при таком запросе, список меток извлекается как-то странно. Если метка одна, то все нормально. Если меток две - то они извлекаеются дважды, если три - то трижды.

Может я че-то напутал?

PS.: Таблицу labels переименовал в articles_labels и грохнул из нее колонку type.

Тогда наверное придется возвращаться к коррелированным подзапросам или вводить третью таблицу labels (назначая ей алиас) специально для извлечения меток.