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

[Ивано++]

Тогда думаю что более смысла что-то искать нет - и полностью поддерживаю Ваше мнение.

И тогда так и получается самым Важным является же опять вопрос именно экспорта/импорто товара - что бы они были всегда актуальными... Ну и к заказам тоже самое... Не совсем понял только что значит резервирование?

--
А по поводу кэширования в typo3...
Я все более и более склонялся к такой теме, что бы страницы (готовый кэш) включать на уровне localconf - единственный минус - это 100% кэш (0 запросов к БД, прктически 0% работы php, нагрузог на хостинг 0) - и как следствие, страница не динамичной получится.

Но потом отказался от этой идеи...
И пришел к следующему выводу - если у меня сайт быстро грузится < 1 секунды на typo3 и даже не на VPS (работает на FLUID, TS, и стандартных шаблонах) - значит можно оставить... Конечно без VPS-уже не потянет 500 и более страниц - т.к. на них будут кроме посетителей, заходить еще роботы - и будет выбиваться ограничение на запросы и работу скриптов...



--
А по поводу FE-модулей так и получается что в любой CMS это дело техики и времени... У меня была один раз задача сделать выгрузку товара (10 штук) для яндекс.маркета на bitrix - не скажу, что мучился - но сделал не элегантно.

Хотя идея была в следующем - просто к товарам добавил поле галочку "Данный товар участвует в Яндекс.маркет" - а если в typo3 создал бы новый тип страницы специально для яндекс.маркета - куда бы кэшированно выгружал список данных товаров...


--
Тогда оставляю себе на заметку функционал http://simplacms.ru/
И больше не терзаюсь данной темой (в т.ч. в голове)...
Просто CMS-магазинов много море - а интересного, компактного, по делу и сущестову очень мало оказалось...

Еще интересный : shop script 5
Спасибо.

[Ивано++]

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

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

Что запрос 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...

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