Форум MySQL

Прошу прощения за дубли тем. Проглючило сеть.

Добрый день. Господа опытные разработчики, помогите советом!

Задача для сайта по поиску вакансий. Дальше речь пойдет о поиске по таблице вакансий.

1. Есть ли смысл в плане производительности сохранять результаты поиска по запросам пользователей в отдельную таблицу (запрос с 3-5 джоинами), чтобы при повторном запросе других пользователей данные тупо забирались из кэш-таблицы по id запроса? Уникальных объявлений - 10000, но реально хранится от 20000 до 100000 записей, т.к. на одну объяву может быть в среднем до 10 клонов (разные метро, направления, отрасли и т.п.)... Запросов в день может быть допустим 1000... результатов по запросу в среднем наверное 100... и того теже 100000 записей...
если запросов будет слишком много, то можно вести их рейтинг и хранить данные только по 1000 самым популярным... также можно ввести ограничение на кол-во записей по результатам запроса

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

P.S. Чтобы не делать лишний раз join, некоторые данные по-мимо id дублирую строковым значением из справочника на этапе импорта вакансий. Допустим metro_id и metro_str. Правильно ли это?

2. И еще небольшой вопросик, касающий того, что было упомянуто в первом. Если в объявлении указано несколько справочных данных (скажем объява касается 10 станций метро), то правильно и логично создавать 10 одинаковых записей с разными метро и указывать id родителя, чтобы по ним в результатах поиска фильтровать дубли?

вот одно из мнений. что скажете?

Hudbrog (15:45:29 23/05/2008)
значит так

Hudbrog (15:45:50 23/05/2008)
1) если требуется сделать 3-5 джойнов, то это просто мега-криво спроектированная БД

Hudbrog (15:46:06 23/05/2008)
2) ничего хранить не надо, ибо нормальные СУБД кеширует

Hudbrog (15:47:47 23/05/2008)
в общем я бы посоветовал перепроектировать БД

Hudbrog (15:47:53 23/05/2008)
как следует подумав

default (16:09:45 23/05/2008)
есть обычная таблица, в которой хранятся вакансии... у кажой вакансии может быть несколько отраслей, метро, образований и т.п.... все они хранятся в справочниках... чтобы не делать джоины, я продублировал текстовые значения из справочников в отдельных столбцах

default (16:10:31 23/05/2008)
2) какие субд нормальные? мускл кэширует?

default (16:11:19 23/05/2008)
судя по тому, что один и тот же сложный запрос выполняется подряд два раза одинаково долго, то нифига он не кэширует

> 1) если требуется сделать 3-5 джойнов, то это просто мега-криво спроектированная БД
Чушь полнейшая

> в общем я бы посоветовал перепроектировать БД
В работающем проекте-то. Угу. самое простое решение. :)

По сабжу. Есть смысл что-то оптимизировать если наблюдаются глюки и тормоза.
У вас наблюдаются?

PS Кешировать запросы к БД в самой БД явно не самое удачное решение.