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

Ивано++ · 09.05.2013, 02:47

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

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

--
А по поводу кэширования в 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
Спасибо.

Ивано++ · 09.05.2013, 03:46

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

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

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

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

-=UncleByte=- · 09.05.2013, 04:09

Симпла пока еще довольно сырая и дорожает от версии к версии. CS-Cart умеет гораздо больше и лучше за те же деньги.

Ивано++ · 09.05.2013, 04:31

Цитата:

Сообщение от -=UncleByte=-

Симпла пока еще довольно сырая и дорожает от версии к версии. CS-Cart умеет гораздо больше и лучше за те же деньги.

Смотрим, изучаем...
Тоже интересная штука - но в нем как мне показалось больше лишнего...

-=UncleByte=- · 11.05.2013, 01:41

Ага, самое ненужное это, конечно, обработка картинок категорий, чего добиться от Симплы в принципе пока не получается не дописав чего-то своего.

Ивано++ · 13.05.2013, 19:43

И еще , прокручивая в голове всевозможные варинты развития событий . остаюсь "неопределенным" по поводу того, как хранить данные.

По идее хранение товаров можно организовать в виде одной таблицы, где в данной можно создать 1 поле (аналог doktype для pages, CType для tt_content) - и мы сможем создавать в рамках одной таблицы разные товары с разным набором свойств....

Так обычно и делают.
Но вот у меня есть один момент, который в голове не совсем укладывается.

К примеру как совместить товары с категориями.
Или к примеру, у нас будет еще какая-то 3-тья таблица....
В которой мы будетм хранить к примеру город (или еще что-то)...

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

Но вопрос в том, будут ли у бухгалтерии данные таблицы - и как они к примеру хранять то, к какой категории принадлежит товар?

Андрей Аксенов · 13.05.2013, 23:13

Естественно при экспорте/импорте обрабатывать придется все таблицы. К тому же, таблиц там много...
Товар, свойства товара, набор параметров для свойств товара, категория товара. К тому же, нужно отразить влияние каждого параметра из свойств на конечную цену (например галоши разного размера будут стоить по разному).
Легче все это проследить на моделях данных уже существующих магазинов, иначе что-то да упустишь. А уж как это отражается в бухгалтерских программах - конечно лучше узнать у бухгалтеров, работающих с интернет магазинами.

Ивано++ · 29.05.2013, 19:24

И снова к данном теме - как к теплому месту.

Собственно есть два вопроса

1. У typo3 - есть какой-то TASK sentr - т.е. как понимаю это центр задач. У многих CMS смотрю есть похожие вещи - в т.ч. синхронизация с БД 1с.

Собственно вопрос - как эти процессы могут происходить если нет обращений к сайту. Ведь данные скрипты по идее все равно должен запускать пользователь - посещяя определенную страницу либо кликая кнопку в панели администирования.

Ведь у PHp-нет никаких функций, которые бы позволили установить комманду на автовыполнение, например в 23:00 - выполнить такой-то скрипт... Ведь это возможно только в настройках хостинга (например рез.копирование - 1 раз в день

Как это вообще может работать в CMS??? которые написаны на PHP?

2. И опять к теме 1С - как в 1С хранятся товары и какая структура-то выгружается на сайт... Ведь я же правильно понимаю что в 1С - хранится только минимум о товарах (а именно цена, остаток, а вот поля свойст, картинки - здесь все это не храниться, а уже забивается на сайте? или как... И получается что когда делается интеграция с 1с - то обновляются только поля товаров - цена, количество...

Или как это?

Андрей Аксенов · 29.05.2013, 22:55

1. Работает через задачи cron и установку соответствующей задачи в планировщике (что не отменяет настройку, соответственно, сервера на проверку установленных в планировщике задач).
2. Фиг его знает, но 1С - та же база данных, а уж все ее "надстройки" - это как раз взаимодействия полей в базе данных - данные берутся из справочников и определенным образом взаимодействуют, а выводятся через соответствующим образом настроенные формы. А для выгрузки существуют какие-то стандартные структуры - вот на это и надо обратить внимание, ведь это, как я понимаю, какие-то стандарты бухгалтерских программ (1С при этом не самая лучшая, просто "народная", "попсовая").

Ивано++ · 29.05.2013, 23:14

Цитата:

Сообщение от Андрей Аксенов

1. Работает через задачи cron и установку соответствующей задачи в планировщике (что не отменяет настройку, соответственно, сервера на проверку установленных в планировщике задач).

В принципе понял - что это такое.
И так понимаю - что это команда хостингу...

09.05.2013, 02:47	#21
Ивано++ Senior Member Регистрация: 18.01.2013 Адрес: Russia , Moscow Сообщений: 796	Тогда думаю что более смысла что-то искать нет - и полностью поддерживаю Ваше мнение. И тогда так и получается самым Важным является же опять вопрос именно экспорта/импорто товара - что бы они были всегда актуальными... Ну и к заказам тоже самое... Не совсем понял только что значит резервирование? -- А по поводу кэширования в 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 Спасибо. __________________ Иван Литовченко http://iv-litovchenko.ru/ Последний раз редактировалось Ивано++; 17.05.2013 в 13:07

09.05.2013, 03:46	#22
Ивано++ Senior Member Регистрация: 18.01.2013 Адрес: Russia , Moscow Сообщений: 796	И с другой стороны... Раз мы затронули тему кэшировани... Не совсем понимаю - почему для многих это является проблемой производительности... Ведь по идее кэширование, что на файлах, что на БД не имеет никакой раздници... Что запрос 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... Что через БД, что через файловые системы - раздницы никакой не будет... __________________ Иван Литовченко http://iv-litovchenko.ru/ Последний раз редактировалось Ивано++; 09.05.2013 в 04:00

13.05.2013, 19:43	#26
Ивано++ Senior Member Регистрация: 18.01.2013 Адрес: Russia , Moscow Сообщений: 796	И еще , прокручивая в голове всевозможные варинты развития событий . остаюсь "неопределенным" по поводу того, как хранить данные. По идее хранение товаров можно организовать в виде одной таблицы, где в данной можно создать 1 поле (аналог doktype для pages, CType для tt_content) - и мы сможем создавать в рамках одной таблицы разные товары с разным набором свойств.... Так обычно и делают. Но вот у меня есть один момент, который в голове не совсем укладывается. К примеру как совместить товары с категориями. Или к примеру, у нас будет еще какая-то 3-тья таблица.... В которой мы будетм хранить к примеру город (или еще что-то)... Получается что весь магазин (экспорт, импорт) будет завязан на значения всех таблиц, которые мы будем желать использовать... Но вопрос в том, будут ли у бухгалтерии данные таблицы - и как они к примеру хранять то, к какой категории принадлежит товар? __________________ Иван Литовченко http://iv-litovchenko.ru/

29.05.2013, 19:24	#28
Ивано++ Senior Member Регистрация: 18.01.2013 Адрес: Russia , Moscow Сообщений: 796	И снова к данном теме - как к теплому месту. Собственно есть два вопроса 1. У typo3 - есть какой-то TASK sentr - т.е. как понимаю это центр задач. У многих CMS смотрю есть похожие вещи - в т.ч. синхронизация с БД 1с. Собственно вопрос - как эти процессы могут происходить если нет обращений к сайту. Ведь данные скрипты по идее все равно должен запускать пользователь - посещяя определенную страницу либо кликая кнопку в панели администирования. Ведь у PHp-нет никаких функций, которые бы позволили установить комманду на автовыполнение, например в 23:00 - выполнить такой-то скрипт... Ведь это возможно только в настройках хостинга (например рез.копирование - 1 раз в день Как это вообще может работать в CMS??? которые написаны на PHP? 2. И опять к теме 1С - как в 1С хранятся товары и какая структура-то выгружается на сайт... Ведь я же правильно понимаю что в 1С - хранится только минимум о товарах (а именно цена, остаток, а вот поля свойст, картинки - здесь все это не храниться, а уже забивается на сайте? или как... И получается что когда делается интеграция с 1с - то обновляются только поля товаров - цена, количество... Или как это? __________________ Иван Литовченко http://iv-litovchenko.ru/

Похожие темы
Тема	Автор	Раздел	Ответов	Последнее сообщение
Освоение Typo3 от начала до конца, всё разжёвано :)	premier	FAQ (Часто задаваемые вопросы)	69	19.04.2007 16:47

09.05.2013, 04:09	#23
-=UncleByte=- Senior Member Регистрация: 14.04.2006 Сообщений: 1,159	Симпла пока еще довольно сырая и дорожает от версии к версии. CS-Cart умеет гораздо больше и лучше за те же деньги.

11.05.2013, 01:41	#25
-=UncleByte=- Senior Member Регистрация: 14.04.2006 Сообщений: 1,159	Ага, самое ненужное это, конечно, обработка картинок категорий, чего добиться от Симплы в принципе пока не получается не дописав чего-то своего.

13.05.2013, 23:13	#27
Андрей Аксенов Senior Member Регистрация: 12.04.2008 Адрес: Россия, Москва Сообщений: 706	Естественно при экспорте/импорте обрабатывать придется все таблицы. К тому же, таблиц там много... Товар, свойства товара, набор параметров для свойств товара, категория товара. К тому же, нужно отразить влияние каждого параметра из свойств на конечную цену (например галоши разного размера будут стоить по разному). Легче все это проследить на моделях данных уже существующих магазинов, иначе что-то да упустишь. А уж как это отражается в бухгалтерских программах - конечно лучше узнать у бухгалтеров, работающих с интернет магазинами.

29.05.2013, 22:55	#29
Андрей Аксенов Senior Member Регистрация: 12.04.2008 Адрес: Россия, Москва Сообщений: 706	1. Работает через задачи cron и установку соответствующей задачи в планировщике (что не отменяет настройку, соответственно, сервера на проверку установленных в планировщике задач). 2. Фиг его знает, но 1С - та же база данных, а уж все ее "надстройки" - это как раз взаимодействия полей в базе данных - данные берутся из справочников и определенным образом взаимодействуют, а выводятся через соответствующим образом настроенные формы. А для выгрузки существуют какие-то стандартные структуры - вот на это и надо обратить внимание, ведь это, как я понимаю, какие-то стандарты бухгалтерских программ (1С при этом не самая лучшая, просто "народная", "попсовая").