С магазинами в Тайпе по-прежнему всё глухо?

[Ивано++]

И с другой стороны...
Раз мы затронули тему кэшировани...

Не совсем понимаю - почему для многих это является проблемой производительности... Ведь по идее кэширование, что на файлах, что на БД не имеет никакой раздници...

Что запрос SELECT
Что запрос к файлу . по скорости одно и тоже...
Ну если конечно не считать запредельные размеры Баз данных - ОЧЕНЬ ОЧЕНЬ ОЧЕНЬ БОЛЬШИЕ...

Помню в инете как то читал заметку одного парня - он ТИПа тестил mysql-возможности - на примере вставки 1 000 000 или миллиарда справочника телефонов - но суть не в количестве, а во времени, за которое этот запрос INSERT у него выполнился (сутки, или трое) - и он удивлялся "Блюдь - как же так - ня это mysql-сервер"...

Я многого до сих пор не понимаю:

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

По идее - почему typo3 грузится определенное время - это все из за for, и foreach (грубо говоря)- когда происходит переборка массивов - вот и все...

Другое дело когда идут сложные запросы
SELECT JOINT - и прочая перекрестщина...
типа как здесь:

PHP код:

SELECT DISTINCT tt_news.uid, tt_news.*
FROM tt_news 
LEFT OUTER JOIN tt_news_cat_mm ON tt_news.uid = tt_news_cat_mm.uid_local
WHERE
    1=1 
    AND (tt_news_cat_mm.uid_foreign IN (32,7,1,33,60)) 
    AND tt_news.sys_language_uid IN (0,-1) 
    AND tt_news.pid > 0  
    AND tt_news.uid NOT IN (11305) 
    AND tt_news.pid IN (85,86,87,88,137,369,520) 
    AND tt_news.deleted=0 
    AND tt_news.t3ver_state!=1 
    AND tt_news.hidden=0 
    AND (tt_news.starttime<=1352798034) 
    AND (tt_news.endtime=0 OR tt_news.endtime>1352798034) 
    AND (tt_news.fe_group='' OR tt_news.fe_group IS NULL OR tt_news.fe_group='0' OR (tt_news.fe_group LIKE '%,0,%' OR tt_news.fe_group LIKE '0,%' OR tt_news.fe_group LIKE '%,0' OR tt_news.fe_group='0') OR (tt_news.fe_group LIKE '%,-1,%' OR tt_news.fe_group LIKE '-1,%' OR tt_news.fe_group LIKE '%,-1' OR tt_news.fe_group='-1'))
ORDER BY datetime DESC
LIMIT 7 


И честно признаться я вообще не совсем-то понимаю зачем в tt_news такие вот запросы есть...
Да еще и эта недопирамида MM.
Hidden, deleted да limit - и этого достаточно выше крыши...
Ну или конечно если хостинг позволяет - то это другое дело...

Поэтому чем проще запросы тем лучше...
А время на for и foreach - это неизбежное...

Ведь на сколько мне известно mysql - это теже файлы (только два - одни структура, другой данные).
Вот представим мы делаем просто запрос к файлу casche.temp - он у нас выполнится за минимум милисекунд.
А если нам еще надо разобрать данные полученные из него, да еще что-то запросить и присоединить из файла casche2.temp...

Что через БД, что через файловые системы - раздницы никакой не будет...