битрикс в какой таблице хранятся товары

Как хранить большое количество характеристики товара?

Вот что Битрикс ответил после недельной переписки:
— проблема не распространенная и вообще не типовой случай.

«Обычно такая задача решается разделением на инфоблоки (по разделам или по типам).
Каких-то штатных средств нет для ускорения продукта при таком количестве свойств.»

«Прочитайте статью наших специалистов по производительности:
https://www.itsumma.ru/blog/problemy-proizvoditelnosti-saytov-na-1c-bitrix
Особенное внимание уделите пункту «Неправильная структурная организация инфоблоков».
Я думаю, что часть вопросов пропадёт.

Если у вас есть предложения по развитию продукта, пишите на наш сайт идей: http://idea.1c-bitrix.ru/
Если доработка понравится другим пользователям и разработчикам, то она будет включена в план на реализацию.»

» Неправильная структурная организация инфоблоков

При этом однажды мы столкнулись с противоположной проблемой: у проекта была правильная структура инфоблоков, но также было много агрегирующих выборок (новинки, акции, хиты). Получилось, что вместо одного запроса в «долгий» инфоблок для генерации выборки отправлялось по запросу в 50+ быстрых инфоблоков и затем ещё происходило их совмещение в коде. Из-за этого компонент в целом стал работать медленнее. Так что если проекту необходима такая функциональность, то надо разрабатывать запасной план — создавать отдельную таблицу в базе данных (делать «денормализацию» структуры инфоблоков), либо через внешнюю агрегацию, либо что-то ещё.»

П.С.
И да, картинок очень много, примерно в 10 раз больше номенклатуры. Подозреваю что огромное кол-во времени тратится на её ресайзинг, наверно на этом тоже можно много сэкономить, если делать его заблоговременно, а саму фичу по ресайзингу в Битриксе вообще не использовать.

Подготовил ссылки на темы по данной проблеме, может кому то полезно будет:

Ребята, я обещал вам написать как это решать, но нет времени. Необходимо переписать несколько файлов.
Сейчас работает при свойствах >4500 в одном инфоблоке + 10 параллельных обменов инкрементальных (они конечно иногда выстреливают в дедлоки, но задачу они свою решают).

Повторюсь, магазин >60к товаров

Проблема в нескольких местах. Смотря что вы используете.

1. построение arResult для секции в плане выбора и выброса всех свойств (они не нужны)
2. обновление и выбор свойств из базы
3. механизм скидок по правилам, которые как текст записаны в базу
ну и т.д.

будет время напишу.

да, и про админ панель с модификацией свойств забудьте
битрикс делается универсальным для не программистов, поэтому отход в сторону админ чтобы там все, конечно ущербный если объемы большие
приходится прибегать к базе руками

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

а вот плодить бесконечное неконтролируемое количество инфоблоков это глупость.
вы же не знаете заранее какие свойства появятся у вновь прибывших товарах в новых направлениях.
ну создайте 100 или 200 инфоблоков и тратте время только на контроль куда какое свойство должно попасть и отображаться. если вам так нам нравится. нам нет.

100-200 инфоблоков тоже перебор, я скорей говорил о 10, ну максимум 20. 100+ инфоблоков тоже ошибка.

Оптимизация выборки в catalog.section это мелочь, еще нужно страницу товар переделать, плюс фильтра, плюс сравнение. Плюс админка, редактирование товара на 8к свойств тоже надо переделывать, плюс редактирование в таблице. Производительность публички хорошо, но об админке то не надо забывать.
Плюс обмен с 1с. Плюс возможные экспорты во внешнии базы, маркет и мерчант например.

Делать свои компоненты это точно не хороший тон, тупо делать ради того что бы было «свое» бессмысленно. После здачи проекта код не обновляеться и менее надежен чем типовой обновляймый и проверенный тестерами команды битрикса. Максимум что вы можете получить так это только придельную оптимизацию для узко-специализированного решения. На типовых компонентах для разделов новости/статьи/каталог/контакты/справка/тд заметного прироста не будет. А код может сдохнуть после обновления ядра или хостинга.
Свой компонент и/или свой модуль нужен на не типовых задачах, типа генерации медиа файлов (jpg, pdf, mp3, тд), выборки не типовых сущностей, формы и виджеты, различные конструкторы/интерактивы и тд. А новости и каталог это самое типовое решение, практически все можно дописать в шаблоне.

Да, битрикс не расчитан на такие цифры в таких сценариях. Да, это можно исправить поправив ядро. Можете предложить свои правки разрабам. Но уверен, что они сами прекрасно все знают. Пока что имеем, то что имеем, и 8к свойств в одном инфоблоке это не решение. Когда то может доработают ядро и можно будет смело столько забивать, но не сейчас.

Модерацию перечня свойств контенщик полюбому делает как минимум для умного фильтра.
Для сценария с одним инфоблоком, я завожу белый список свойств, с интерфейсом в админке. В нем указываються перечень свойств для фильтрации и редактирования, только они и импортируються в инфоблок. все остальное у меня храниться в отдельной таблице и подгружаеться в шаблоне. За одно тут же расширенный функционал по валидации/нормализации/обьединения/подмены/парсинга/тд значений свойств. Если нужно редактируемое свойство, то оно вноситься контенщиком в белый список и следующей синхронизацией автоматом создаеться и заполняеться с сответсвующих баз(1с, яндекс маркет, прайсы, апи дестрибьютеров).

Ну не нужны 8к свойств в инфоблоке. Минимум 90% таких свойств, просто справка и дубликаты с путаницей написания, и их можно хранить более дешевыми методами.

Так выходит минимальное количество правок, максимальная производительность публички и админки, масштабируемость базы, целое ядро.

Дело не в нагрузке базы, таблицы для 100к товаров с 10к свойств это копейки. Разбивай по отдельным таблицам или нет, толком нечего не даст. Для MySQL это не те цифры.

Проблема чисто в админской оснаске и типовых компонентов вывода. Формы редактирования элемента или списка элементов. Редактирование настроек.

На таких цифрах должна быть ajax с отдельным редактирования каждого поля, а не как щяс в редактировании инфоблока вываливаться стандартная форма с 100к+ полей, ведь на каждое свойство десяток input. Это все равно что бы если свойств не было и мы редактировали бы абсолютно все товары каталога на одной единственной странице. Нужна оптимизация и переделка всех форм инфоблока. Плюс нужно оптимизировать выборки в компонентах, не выхватывать все 10к свойств на каждый товар, а только нужные. В АПИ скорее всего надо еще оптимизировать некоторые выборки, например в индексации поиском.

И тогда будет все летать на одном инфоблоке. База, а точнее её схема, к данной проблеме не имеет отношения. Можно и нужно схему/архитектуру улучшить, но это не связанная задача.

Привязка свойств к разделу есть и это нечего не дает и не теряет в скорости текущих таблиц. Лиш уменьшает выборки в определенных сценариях и некоторые формы.

Да, архитектура «кривая», но это в наше время, хоть проблема напрямую не в ней. Когда её задумывали и реализовали все летало и таких проблем не было. Новые реалии требуют новую архитектуру.

Отдельное замечание:
Добавление новых инфоблоков одного каталога не требует редактирования кода. А если требует то это бага от разраба. Не каких «мы подписываемся на вечную доработку» и не каких «пляски с бубном». Я даю гарантию два года на свои разработки/интеграции и мне не выгодно что бы постоянно дергали по таким пустякам.
Добавление разделов в выгрузку, ну это уж очень элементарно, хоть пару кнопок то клацнуть то можно же. Или вы как то не так настраиваете структуру разделов.

«Почему тогда 99% решений из маркетплейса», ну тут я боюсь обидеть других разработчиков, и схватить бан, Но почти все вопросы/проблемы такого типа один ответ: «Потому, что 99% решений в маркетплейса откровенный гов**код» и задуманны чисто зарабатывать с продажи, а не работы/поддержки. Продал и забыл.

И снова же «решения» не связанны с проблемой данной ветки и они не должны их решать.

Плюс, по идее большенство «решений» должны спокойно работать с каталогом на множетсве инфоблоков. Просто корявые «мастер настройки» не продуман или демо данные такие. А так думаю готовые решения спокойно и быстро дорабатываються для конкретно данной функции.

Источник

Как хранить большое количество характеристики товара?

Вот что Битрикс ответил после недельной переписки:
— проблема не распространенная и вообще не типовой случай.

«Обычно такая задача решается разделением на инфоблоки (по разделам или по типам).
Каких-то штатных средств нет для ускорения продукта при таком количестве свойств.»

«Прочитайте статью наших специалистов по производительности:
https://www.itsumma.ru/blog/problemy-proizvoditelnosti-saytov-na-1c-bitrix
Особенное внимание уделите пункту «Неправильная структурная организация инфоблоков».
Я думаю, что часть вопросов пропадёт.

Если у вас есть предложения по развитию продукта, пишите на наш сайт идей: http://idea.1c-bitrix.ru/
Если доработка понравится другим пользователям и разработчикам, то она будет включена в план на реализацию.»

» Неправильная структурная организация инфоблоков

При этом однажды мы столкнулись с противоположной проблемой: у проекта была правильная структура инфоблоков, но также было много агрегирующих выборок (новинки, акции, хиты). Получилось, что вместо одного запроса в «долгий» инфоблок для генерации выборки отправлялось по запросу в 50+ быстрых инфоблоков и затем ещё происходило их совмещение в коде. Из-за этого компонент в целом стал работать медленнее. Так что если проекту необходима такая функциональность, то надо разрабатывать запасной план — создавать отдельную таблицу в базе данных (делать «денормализацию» структуры инфоблоков), либо через внешнюю агрегацию, либо что-то ещё.»

П.С.
И да, картинок очень много, примерно в 10 раз больше номенклатуры. Подозреваю что огромное кол-во времени тратится на её ресайзинг, наверно на этом тоже можно много сэкономить, если делать его заблоговременно, а саму фичу по ресайзингу в Битриксе вообще не использовать.

Подготовил ссылки на темы по данной проблеме, может кому то полезно будет:

Ребята, я обещал вам написать как это решать, но нет времени. Необходимо переписать несколько файлов.
Сейчас работает при свойствах >4500 в одном инфоблоке + 10 параллельных обменов инкрементальных (они конечно иногда выстреливают в дедлоки, но задачу они свою решают).

Повторюсь, магазин >60к товаров

Проблема в нескольких местах. Смотря что вы используете.

1. построение arResult для секции в плане выбора и выброса всех свойств (они не нужны)
2. обновление и выбор свойств из базы
3. механизм скидок по правилам, которые как текст записаны в базу
ну и т.д.

будет время напишу.

да, и про админ панель с модификацией свойств забудьте
битрикс делается универсальным для не программистов, поэтому отход в сторону админ чтобы там все, конечно ущербный если объемы большие
приходится прибегать к базе руками

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

а вот плодить бесконечное неконтролируемое количество инфоблоков это глупость.
вы же не знаете заранее какие свойства появятся у вновь прибывших товарах в новых направлениях.
ну создайте 100 или 200 инфоблоков и тратте время только на контроль куда какое свойство должно попасть и отображаться. если вам так нам нравится. нам нет.

100-200 инфоблоков тоже перебор, я скорей говорил о 10, ну максимум 20. 100+ инфоблоков тоже ошибка.

Оптимизация выборки в catalog.section это мелочь, еще нужно страницу товар переделать, плюс фильтра, плюс сравнение. Плюс админка, редактирование товара на 8к свойств тоже надо переделывать, плюс редактирование в таблице. Производительность публички хорошо, но об админке то не надо забывать.
Плюс обмен с 1с. Плюс возможные экспорты во внешнии базы, маркет и мерчант например.

Делать свои компоненты это точно не хороший тон, тупо делать ради того что бы было «свое» бессмысленно. После здачи проекта код не обновляеться и менее надежен чем типовой обновляймый и проверенный тестерами команды битрикса. Максимум что вы можете получить так это только придельную оптимизацию для узко-специализированного решения. На типовых компонентах для разделов новости/статьи/каталог/контакты/справка/тд заметного прироста не будет. А код может сдохнуть после обновления ядра или хостинга.
Свой компонент и/или свой модуль нужен на не типовых задачах, типа генерации медиа файлов (jpg, pdf, mp3, тд), выборки не типовых сущностей, формы и виджеты, различные конструкторы/интерактивы и тд. А новости и каталог это самое типовое решение, практически все можно дописать в шаблоне.

Да, битрикс не расчитан на такие цифры в таких сценариях. Да, это можно исправить поправив ядро. Можете предложить свои правки разрабам. Но уверен, что они сами прекрасно все знают. Пока что имеем, то что имеем, и 8к свойств в одном инфоблоке это не решение. Когда то может доработают ядро и можно будет смело столько забивать, но не сейчас.

Модерацию перечня свойств контенщик полюбому делает как минимум для умного фильтра.
Для сценария с одним инфоблоком, я завожу белый список свойств, с интерфейсом в админке. В нем указываються перечень свойств для фильтрации и редактирования, только они и импортируються в инфоблок. все остальное у меня храниться в отдельной таблице и подгружаеться в шаблоне. За одно тут же расширенный функционал по валидации/нормализации/обьединения/подмены/парсинга/тд значений свойств. Если нужно редактируемое свойство, то оно вноситься контенщиком в белый список и следующей синхронизацией автоматом создаеться и заполняеться с сответсвующих баз(1с, яндекс маркет, прайсы, апи дестрибьютеров).

Ну не нужны 8к свойств в инфоблоке. Минимум 90% таких свойств, просто справка и дубликаты с путаницей написания, и их можно хранить более дешевыми методами.

Так выходит минимальное количество правок, максимальная производительность публички и админки, масштабируемость базы, целое ядро.

Дело не в нагрузке базы, таблицы для 100к товаров с 10к свойств это копейки. Разбивай по отдельным таблицам или нет, толком нечего не даст. Для MySQL это не те цифры.

Проблема чисто в админской оснаске и типовых компонентов вывода. Формы редактирования элемента или списка элементов. Редактирование настроек.

На таких цифрах должна быть ajax с отдельным редактирования каждого поля, а не как щяс в редактировании инфоблока вываливаться стандартная форма с 100к+ полей, ведь на каждое свойство десяток input. Это все равно что бы если свойств не было и мы редактировали бы абсолютно все товары каталога на одной единственной странице. Нужна оптимизация и переделка всех форм инфоблока. Плюс нужно оптимизировать выборки в компонентах, не выхватывать все 10к свойств на каждый товар, а только нужные. В АПИ скорее всего надо еще оптимизировать некоторые выборки, например в индексации поиском.

И тогда будет все летать на одном инфоблоке. База, а точнее её схема, к данной проблеме не имеет отношения. Можно и нужно схему/архитектуру улучшить, но это не связанная задача.

Привязка свойств к разделу есть и это нечего не дает и не теряет в скорости текущих таблиц. Лиш уменьшает выборки в определенных сценариях и некоторые формы.

Да, архитектура «кривая», но это в наше время, хоть проблема напрямую не в ней. Когда её задумывали и реализовали все летало и таких проблем не было. Новые реалии требуют новую архитектуру.

Отдельное замечание:
Добавление новых инфоблоков одного каталога не требует редактирования кода. А если требует то это бага от разраба. Не каких «мы подписываемся на вечную доработку» и не каких «пляски с бубном». Я даю гарантию два года на свои разработки/интеграции и мне не выгодно что бы постоянно дергали по таким пустякам.
Добавление разделов в выгрузку, ну это уж очень элементарно, хоть пару кнопок то клацнуть то можно же. Или вы как то не так настраиваете структуру разделов.

«Почему тогда 99% решений из маркетплейса», ну тут я боюсь обидеть других разработчиков, и схватить бан, Но почти все вопросы/проблемы такого типа один ответ: «Потому, что 99% решений в маркетплейса откровенный гов**код» и задуманны чисто зарабатывать с продажи, а не работы/поддержки. Продал и забыл.

И снова же «решения» не связанны с проблемой данной ветки и они не должны их решать.

Плюс, по идее большенство «решений» должны спокойно работать с каталогом на множетсве инфоблоков. Просто корявые «мастер настройки» не продуман или демо данные такие. А так думаю готовые решения спокойно и быстро дорабатываються для конкретно данной функции.

Источник

Битрикс в какой таблице хранятся товары

Курс предназначен для администраторов интернет-магазинов, работающих на базе системы «1С-Битрикс: Управление сайтом». Изучение курса необходимо при работе с продуктом редакции Малый бизнес и выше при организации торговых операций через Интернет.

Поэтому, если у вас нет возможности обновить продукт и/или выполнить конвертацию, то описание работы с модулем Интернет-магазин смотрите в курсе Магазин до конвертации (до версии 15.0).

Кроме того, доступны для скачивания в формате CHM следующие материалы с описанием старого функционала магазина:

Курс Администратор. Бизнес завершает группу административных курсов по Bitrix Framework.

Начальные требования

Необходимый минимум знаний для изучения курса:

Неплохо было бы иметь базовые навыки установки и администрирования *nix-систем.

У нас часто спрашивают, сколько нужно заплатить

Ещё у нас есть Академия 1С-Битрикс, где можно обучиться на платной основе на курсах нашей компании либо наших партнёров.

Баллы опыта

уроке.

Тесты и сертификат

После изучения курса вам будет предложено пройти тесты на сертификацию. При успешной сдаче последовательности тестов на странице Моё обучение можно просмотреть результат обучения и загрузить сертификат в формате PDF.

Для преподавания оффлайн

Если данный курс берётся в качестве основы для оффлайного преподавания, то рекомендуемая продолжительность: 2 дня (16 академических часов).

Если нет интернета

Скачать материалы курса в формате EPUB. Файлы формата EPUB Чем открыть файл на
Android:
EPUB Reader
CoolReader
FBReader
Moon+ Reader
eBoox

iPhone:
FBReader
CoolReader
iBook
Bookmate

Windows:
Calibre
FBReader
Icecream Ebook Reader
Плагины для браузеров:
EpuBReader – для Firefox
Readium – для Google Chrome

Как проходить учебный курс?

Источник

Где хранить все данные о товарах? В 1С или на сайте?

Есть интернет-магазин с каталогом товаров, количество товаров порядка 10000, у каждого товара есть список его характеристик. Плюс большое количество фотографий, файлов с инструкциями и тд к каждому товару.

Коллеги, помогите нам с решением данного принципиального вопроса, возникшего внутри компании. Так вот вопрос, где правильно хранить все данные о товарах, 1С или на сайте?

Оценить 1 комментарий

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

*Все описания удобнее хранить на стороне битрикса, потому что как минимум сеошнику и контент-менеджеру удобнее работать на сайте, а не в 1Ске. Во-вторых разграничить права проще в битриксе (что бы они могли править только описание товара и не имели доступа к ценам, остаткам и заказам). В третьих если сеошник или контент-менеджер внешние сотрудники, то не нужно заморачиваться с удалённым доступом к 1С.

Источник

Интернет-магазин. Настройки модуля

После того, как вы установили модуль Интернет-магазин, сначала необходимо правильно его настроить.

Форма настроек модуля Интернет-магазин (Настройки > Настройки продукта > Настройки модулей > Интернет-магазин) предназначена для задания общесистемных параметров модуля. Для удобства работы форма разделена на закладки, на каждой из которых выполняется настройка определённой группы параметров модуля.

Настройки

Закладка служит для настройки основных параметров модуля Интернет-магазина.