w moich projektach stosuje zapytania typu

[PHP] pobierz, plaintext 
<?php
catsFinder::getById(12);
?>
[PHP] pobierz, plaintext 

to samo jesli chodzi o userów, grupy userów, newsy - ogolnie get by id, get by parent, get all itp itd. Jestem zmuszony pisać w ten sposob - programisci uzywają potem 'klocków' do składania strony. Wracając do tematu - pomysłu... uruchamiając np 10 razy funkcje z rodziny 'byId' wykonuje 10 zapytań co oczywiscie jest mi nie na reke... wpadłem na pomysł, aby funkcja liczyła wewnątrz, który raz w tym requescie jest wywoływana i teraz... jeśli jest to > 3 razy zapisuje w bazie//configu ze nastepnym razem przy tym samym urlu funkcja ma wykonać select * ... a potem wybierać rezultat przy poszczególnych wywołaniach dla poszczególnych wartości wejsciowych. Napisałem swego czasu 'object map' - klasa do ktorej przekazuje wszystkie selecty, i przy następnych pierw sprawdzam czy przypadkiem nie mam juz rezultatu wpisanego w niej, jesli mam to jest z tamtad pobierany a zapytanie jest pomijane. Teraz nasuwa sie pytanie... czy select * będzie wydajniejsze od 5, 10 , 20 select * where id = '' ? moze ktos ma jakis inny pomysł na podniesienie wydajności?

Jeśli chodzi o cache... cache jest zaimplementowany - nie jest to cos szczegolnego - przy kazdym update czyszczony jest cały - z prostego powodu - niektóre zapytania wygladają tak:

[SQL] pobierz, plaintext 
SELECT c.lang = 'pl' AS validLang, c.*, pl_c.lang AS lang_pl, en_c.lang AS lang_en, de_c.lang AS lang_de FROM nccms_cats AS c LEFT JOIN nccms_cats AS pl_c ON c.id = pl_c.id AND pl_c.lang = 'pl' LEFT JOIN nccms_cats AS en_c ON c.id = en_c.id AND en_c.lang = 'en' LEFT JOIN nccms_cats AS de_c ON c.id = de_c.id AND de_c.lang = 'de' WHERE c.parent = 0 ORDER BY priority DESC, validLang DESC
[SQL] pobierz, plaintext 

oczywiście mozna dbać na poziomie zapytania, cache dla których tabel ma być oprózniany - ja niestety musz dbać o programistów leni - takich jak ja, którzy czesto sie mylą, i to skrypt ma dbac o to co usunąć i kiedy usunąć.

Twoje pytanie sprowadza sie do problemu strategi budowy drzew sqlowych.

Przy klasaycznym podejsciu do drzew strukture buduje sie w oparciu o id rodzica. Podstawowym problemem w takim wypadku nie jest dublowanie zapytan tylko liczba unikalnych zapytac. W koncu jak biegasz po drzewie to dla danego elementu jego dzieci mozesz pobrac jednym zapytaniem ale juz wnkukow pobierzesz powtarzajac zapytanie o potomkow dla kazdego dziecka. Oczywiscie buforowanie zapytan tez sie przydaje bo jesli w danym requescie dwa razy wyswietlasz drzewo (lub jego czesc) to po co dwa razy pobierac je z bazy danych.

Przy małych drzewach niekiedy warto pobrac je w calosci i obrabiac po stronie php. Przy wiekszych to sie nie sprawdza i w takich wypadkach trzeba sięgnąć do bardziej wyszukanych metod. Było już na ten temat parę razy na tym forum. Poczytaj o drzewach depesza, poczytaj o zbiorach zagniezdzonych czyli nested sets.