> Kolejny raz napiszę, że to bzdurne podejście.

To prawda - lecz nie rozwijasz wątku. Bzdurne bo Ty stosujesz inne
rozwiązanie? To słaby argument.

> Przyznaj się, że gubisz
> się w kodzie przy ilości tabel > 1, a nie teorie sobie dorabiasz.

Po pierwsze tabel mam 96 i jakoś nie gubię się w tym, po drugie
chciałbym abyś wykazał iż tyle samo czasu CPU zajmie zapytanie
składające się z SELECT * FROM tabela oraz SELECT * FROM tabela JOIN
inna_tabela JOIN jeszcze_inna JOIN kolejna. Nie wiem na czym opierasz
swoje twierdzenie, że takie rozbudowywanie zapytań SQL w niczym nie
szkodzi. Otrzymałem skrajnie odmienne wyniki pomiarów.

> Szczególnie, że dalej twierdzisz, że wrzucasz kontent do cache, co
> powinno dodatkowo niwelować narzut na bazę. Tak w ogóle, MySQL też
> potrafi keszować sobie zapytania, czyli oszczędzasz co najwyżej na
> czasie generowania treści.

Akurat nie stosuję MySQL'a aby wypowiadać się w sprawie tej bazy lecz
wydaje mi się ciekawym zagadnienie cache'owania zapytań przez samą bazę.
Nie wyobrażam sobie jak taki mechanizm może funkcjonować jeśli baza "nie
wie" co najczęściej będzie czytane i jak dalej przetwarzane i w związku
z tym co należy cacheować. W innych bazach: PostgreSQL, M$ SQL nie
zaobserwowałem takiego mechanizmu o jakim piszesz dla zapytań typu
SELECT * FROM tabela WHERE tabela_id=losowy_id (bo nie można przewidzieć
o jaki ID będzie zapytanie). Zapytanie pochłania znacznie więcej taktów
CPU niż odczyt z cache tych samych informacji a już nie wspomnę o danych
przetworzonych wstępnie - głównie to jest przedmiotem cacheowania w moim
CMS a nie same zapytania SQL. Są to np. wyniki rekurencyjnych zapytań
SQL często powtarzanych przy odwiedzaniu serwisu WWW - np. dla struktur
menu, kategorii i innych hirerchii, wstępnie przetworzone fragmenty
stron WWW, które nie muszą być dynamicznie aktualizowane itp.