Регистрация
Вход через соцсети
Восстановление пароля

Крупный интернет магазин на одном компоненте товара

Новый топик
24.07.2014, 12:02
Ответить | Цитировать
Вячеслав
ruCreate
Вячеслав

Зарегистрирован:
2013-04-12
Сообщений: 87

Всем здравствуйте!

Как то на досуге рассуждал о создании крупного интернет магазина на cms netcat.
Возьмем магазин крупной компании, к примеру «ситилинк» или «комус». Там скажем товара по 100 000 и больше. Сайты написаны программистами на фреймворке, т.е. свой движок. Магазины сложные, имеют кучу выборок по заданным критериям из разных разделов разных товаров. Программисты во многих случаях утверждают, что товар должен находится в одной таблице. Предполагаю, что в этих магазинах так и есть.

Скажем, если собирать подобный магазин на cms netcat, необходимо будет создавать на каждый раздел (1. Компьютеры, 2. Мебель, 3. Канцтовары) отдельный компонент товара, т.е. это будут разные таблицы MessageXXX. Сточки зрения удобства дальнейших доработок на мой взгляд это не совсем правильно. Да есть глобальные переменные для версии интернет магазина в cms, я могу положить в корзину, вытащить картинку и прочее...

Нельзя делать на одном компоненте товара (в одной таблице MessageXXX), т.к. необходимо задавать свои критерии выборок товара для каждого раздела. Наполнение редактором сайта для удобства будут создаваться списки. В этих списках может содержаться до 5000 наименований и этих полей «список» может быть более 100, и все это в одной таблице. Естественно такая конструкция будет работать жутко медленно, если вообще будет.

Вопрос в том, как реализовать крупный магазин на netcat в одном компоненте товара в одной таблице MessageXXX, чтобы не пришлось ломать саму cms.
Может у кого то есть магазин с товаром более 20 000 наименований собранный на данной cms и сможет поделится мнением?
27.07.2014, 17:44
Ответить | Цитировать
Руслан Густокашин
Студия Вэлпис
Руслан Густокашин

Зарегистрирован:
2012-02-06
Сообщений: 869

Да, это очень насущная проблема для крупных магазинов - как для разнородных товаров сделать единую форму поиска(выборки) или как уместить такие товары в один компонент, чтобы воспользоваться обычной выборкой. Я для себя накопил такие интересные идеи, помогающие в решении этих задач:
1. Делаем в системной таблице "Разделы" некое доп.поле "тип товара в разделе", и для каждого такого типа товара создаем любым удобным способом сущность, в которой будет храниться перечень свойств (полей), присущих тем или иным типам товаров. При редактировании или добавлении товара, пользуемся альтернативной формой, в коде которой выводим только нужные нам поля и только с нужными нам данными выпадающих списков в них. В Списках в дополнительном поле указываем тип товара, к которому относится то или иное значение. Получаем довольно удобную форму редактирования. Но это решение удобно, если количество полей не безумно большое. А работает вполне шустро.
2. Если количество из-за разнородности товаров получается чересчур большое, то нужно поля (свойства товаров) выносить в отдельный компонент и оттуда дергать данные. Работать будет медленнее и программировать довольно сложно. Но можно. улыбка
3. Другой вполне рабочий вариант взамен п.2 - создаем в товарном компоненте лишь 20 полей вида Property01....Property20, и в "Пользовательских настройках" компонента задаем для каждого свойства свое название.
Тогда если добавите в какой-то раздел инфоблок с таким компонентом, в настройках инфоблока появятся эти самые 20 полей, где можно ввести их названия. Эти названия можно отображать и в списке товаров и на детальной странице товара через $cc_settings. Также названия этих полей можно выдергивать и в формах редактирования и добавления товара.
В форме выборки придется немного покуралесить, чтобы получилась единая форма для всех типов товаров, но требуемый результат вполне достижим. :-)
4. Создать все-таки несколько товарных компонентов, но вместо "компонентной" формы выборки воспользоваться скрытыми улыбка возможностями модуля "Поиск по сайту". Данный модуль позволяет через xpath выдергивать из индексируемых страниц те или иные данные прямо из HTML (в момент переиндексации сайта) и сохранять их в поисковом индексе в виде отдельных полей. И по этим полям можно делать выборку, генерируя с этой целью особую форму поиска.

Первые три решения я уже применял, все нормально, а над четвертым способом как раз сейчас работаю. Есть некоторые подводные камни и ограничения, но уже почти победил их (в рамках своей задачи), так что должно все получиться.
А так вообще чаще всего мне приходилось идти либо первым способом (если полей не более 50), либо третьим (для огромного количества очень разнородных товаров в крупном магазине).

Ну и еще одно замечание: мне кажется, что для складского учета 20 тыс.товаров неткат не очень удобен. Лучше вести основные характеристики товаров, например, в 1С и оттуда регулярно перекачивать данные в неткат. А на неткате заниматься, например, редактированием только SEO-полей и описаниями.

04.08.2014, 14:50
Ответить | Цитировать
Вячеслав
ruCreate
Вячеслав

Зарегистрирован:
2013-04-12
Сообщений: 87

Интересен 3-ий вариант.
Как "выдергивать и в формах редактирования и добавления товара"?
Хотелось бы примерно так:
все таки собирать на одном компоненте весь магазин, но в форме добавления/редактирования объекта выводились именно те поля, которые относятся к данному разделу (компьютеры, мебель, ...). По скольку в основной таблице MessageXXX хранятся в основном значения из списков (1,2,3 и т.д.), то весит она не так уж и много. У меня к примеру таблица с количеством товара 2000 единиц весит всего 1.5 мб.
Больше всего приходится извращаться с сокращением кода для вывода значений.
Подошел бы такой вариант, чтобы при редактирования поля в инфоблоке можно было бы указать к чему это поле относится к 1. Компьютерам, 4. Мебели и т.д.
05.08.2014, 10:18
Ответить | Цитировать
Гость
Гость

а тормоза базы MySQL не считали?
что мешает объединять запросы?
и где могут например сапоги с телевизорами выводиться?
05.08.2014, 10:26
Ответить | Цитировать
Вячеслав
ruCreate
Вячеслав

Зарегистрирован:
2013-04-12
Сообщений: 87

Тормоза тоже будут при объединении 30 таблиц.
Сапоги с вашими колесами должны выводится из одного макета дизайна, загружаться из одного прайс листа в одну таблицу товара
198 196 2014-08-05 10:26:35 13753
Описание проекта