Ответ

volirvag 30.05.2011 17:43

1. почему используются именно LEFT JOIN-ы? "AND itypes.typesid = 1" означает, что как минимум для ibase_itypes и itypes лучше использовать INNER JOIN-ы.

иннер джоины - это ок. да.

чуть поясню по таблицам:
ibase - основная инфа,
igeo - список значений,
ibase_igeo - промежуточная таблица с внешними ключами (сейчас одна запись ibase может содержать одну запись igeo),
itypes - ещё один список значений,
ibase_itypes - промежуточная таблица с внешними ключами (сейчас одна запись ibase может содержать несколько itypes)

в итоге всё это менюшится (для каждого ibase - одно igeo и несколько itypes).

2. для чего вы хотите разбивать запрос? если он вызывает проблемы с производительностью, то это оно (и начинать надо с EXPLAIN), если "чтоб было" или "говорят, что надо разбивать" -- это другое.

записей пока минимум. с эксплейном не начинал. я вот и спрашиваю вашего опыта, как лучше делать. может быть я вообще не туда копаю и нужно по-иному делать.
записей в таблице ibase планируется до 1000, ibase_igeo тоже 1000 (если 1 к 1), в ibase_itypes - примерно 4000 (1 ко многим).

3. как часто выполняется этот запрос? если раз в сутки -- забейте на него и займитесь чем-нить более полезным.

в том то и дело, что этот запрос основной. он формирует картотеку, которая в разных разделах меню отоображает свои igeo или itypes, отсюда у меня в запросе и "AND itypes.typesid = 1". то есть, если планирую 10 разделов меню, то 10 таких запросов с разными itypes.typesid = 1, 2, 3,..
жутко как-то.. как лучше организоваться в этом случае?

4. кроме производительности запроса есть ещё удобство написания кода и рессурсоёмкость кода. предположим, что в itypes.typesname бывают строки по пол килобайта, и запросом достаётся по 1000 записей. получается, что для отображения этим itypes.typesname просто достаётся дополнительно пол мегабайта строк (а у нас работает cgi), хотя самих записей в таблице itypes -- 10. тут удобнее заранее достать в хеш все эти записи, а выводить строки при используя хэш-лукапы. т.е. из запроса join уберётся, но не потому, что он именно там мешается, а потому, что сделать иначе -- удобнее и менее рессурсоёмко.

это дело конечно, но с реализацией на моём уровне будет проблематично. можете примерчик привести c хэш-лукапами?

---