Приветствую! Подскажите начинающему разработчику, в каких случаях нужно создавать новый тип инфоблока, и для чего это нужно?
Конкретный пример: В установленном Битриксе есть тип инфоблоков "Каталоги" в котором находится инфоблок "Продукция". Для каждого элемента продукции нужно задать конкретного производителя. Для создания инфоблока "Производители" нужно создавать свой тип инфоблоков или можно использовать тип "Каталоги"?
нужно: в первую очередь для удобства в эксплуатации во вторую - у типа инфоблока можно задать ряд параметров, которые будут наследоваться инфоблоками, в него входящими (например использовать древовидный класс. групп)
Алексей Коваленко пишет: нужно: в первую очередь для удобства в эксплуатации во вторую - у типа инфоблока можно задать ряд параметров, которые будут наследоваться инфоблоками, в него входящими (например использовать древовидный класс. групп)
Благодарю, Алексей! Если удобство опустить (в чём оно проявляется?) и предположить что ряд параметров у всех инфоблоков будет одинаков, есть практические рекомендации по созданию для каждого инфоблока своего типа?
По большому счету, можно разделить на 2 типа - есть разделы или нет разделов. А как группировать их по другим признакам зависит от вас (по тематике, по структуре на сайте). Есть еще компоненты, которые выводят инфу из разных инфоблоков (news.line - например) - такие инфоблоки удобно объединить в один тип
Прекрасная жизнь начинается с прекрасных мыслей...
Приветствую! Подскажите начинающему разработчику,кк можно создать прокрутку изображении (или слайдеры) по горизонтально в шапке шаблона в битриксе...у меня битрикс управление сайтом 10 версия (старт)...помогите срочно нужно
Евгений Малков пишет: Есть еще компоненты, которые выводят инфу из разных инфоблоков (news.line - например) - такие инфоблоки удобно объединить в один тип
точно я бы назвал это в-третьих иногда ну очень полезно
Вы упускаете главный вопрос и смотрите не в ту сторону, мне кажется. Правильно ставить вопрос так - В каких случаях НЕ нужно создавать новый тип инфоблока?
Вот пример, у меня пара сайтов сейчас на обслуживании... Первый уровень разделов каталога товаров - ВНЕЗАПНО типы ифоблоков. Второй уровень - инфоблоки. Нет слов. Ну ребята - вообще нет слов. Двенадцать типов только под каталог. В них около сотни ИБ... На одном из сайтов используется фильтр по товаром. Из-за того, что в каждом инфоблоке есть свойство CANTRY (страна происхождения), то этих свойств в таблице свойств 120 кажется или что-то рядом. И вот в фильтре, они фильтруются по значению этого свойства, которое указано по коду. Конец немного предсказуем - 15 секунд на генерацию если фильтруем только по стране, если еще и по цвету то около сорока, ну а если добавить еще какое-нибудь подобное свойство, страница вылетает по таймауту, база становится колом на 20 минут, сайт все это время лежит... Понятно, что быстренько заменил коды свойств на их ID в фильтре и клиент прыгал от радости видя как страница генерится за пару секунд при даже очень сложно фильтре, но это же не выход. Ошибка в архитектуре!
Suntechnic пишет: Вы упускаете главный вопрос и смотрите не в ту сторону, мне кажется. Правильно ставить вопрос так - В каких случаях НЕ нужно создавать новый тип инфоблока?
Вот пример, у меня пара сайтов сейчас на обслуживании... Первый уровень разделов каталога товаров - ВНЕЗАПНО типы ифоблоков. Второй уровень - инфоблоки. Нет слов. Ну ребята - вообще нет слов. Двенадцать типов только под каталог. В них около сотни ИБ... На одном из сайтов используется фильтр по товаром. Из-за того, что в каждом инфоблоке есть свойство CANTRY (страна происхождения), то этих свойств в таблице свойств 120 кажется или что-то рядом. И вот в фильтре, они фильтруются по значению этого свойства, которое указано по коду. Конец немного предсказуем - 15 секунд на генерацию если фильтруем только по стране, если еще и по цвету то около сорока, ну а если добавить еще какое-нибудь подобное свойство, страница вылетает по таймауту, база становится колом на 20 минут, сайт все это время лежит... Понятно, что быстренько заменил коды свойств на их ID в фильтре и клиент прыгал от радости видя как страница генерится за пару секунд при даже очень сложно фильтре, но это же не выход. Ошибка в архитектуре!
Спасибо за подробный ответ, описаны "грабли", на которые не хочется наступать! Было подозрение что они там лежат)))
Пришёл к выводу что первый уровень каталога товаров лучше всего делать Инфоблоком, т.е. для каждой группы товаров свой инфоблок, НО наткнулся на такой пример создания архитектуры (источник http://www.bexx.ru/module/arch.htm):
Цитата
Архитектура каталога товаров В стандартном интернет-магазине на "1С-Битрикс" у вас есть два основных варианта организации каталога товаров на основе инфоблоков. У обоих вариантов есть свои преимущества и недостатки. Рассмотрим сначала оба. В качестве условного интернет-магазина будет рассматривать относительно большой сайт с разнородными товарами, которые обладают различными характеристиками. Например, в нашем условном интернет-магазине продается электроника всего лишь трех видов: ноутбуки, телевизоры, мобильные телефоны. Допустим, каждый тип товара имеет по 10 характеристик, например, для ноутбуков этими характеристиками будет: частота процессора, тип процессора, диагональ экрана, разрешение экрана, объем жесткого диска и т.д. 10 наверное даже мало, в реальных условиях таких характеристик могут быть десятки. Итак,
1. Все товары в одном инфоблоке Имеется один единственный инфоблок "Каталог товаров", в нем хранятся товары всех типов вместе. Типы товаров разделяются только группами в инфоблоке (разделы инфоблока). А вот все характеристики придется хранить вместе. В итоге получаем 10 х 3 дополнительных свойств инфоблока и все они будут видны при редактировании товара. Редактировать партянку в несколько экранов не очень удобно. А если свойств десятки и типов товаров десяток? Такое редактировать нормально уже невозможно. Плюсы: простая архитектура в базе данных, простая логика для вывода товаров. Минусы: неудобное управление товаром, неудобство подбора и сравнения товаров, проблемы при расширении функционала, экспотенциальный рост нагрузки при увеличении типов товаров.
2. Все типы товаров в отдельных инфоблоках Разные типы товаров хранятся в различных инфоблоках. Этот способ организации каталога товаров более продвинутый, чем первый, но также не совершенен. Обычно отдельный инфоблок требует отдельной страницы для вывода. Таким образом вам необходимо будет создавать для каждого типа товаров отдельную страницу для вывода каталога товаров, устанавливать на ней компонент каталога товаров и настраивать его. Также появляются сложности управления товаров. К примеру, если контент-менеджер не знает какой товар где находится, ему придется перебрать все инфоблоки, потому что в 1С-Битрикс нет фильтра по всем инфоблокам в админке, есть только фильтр внутри одного инфоблока. Другая сложность заключается в дублировании свойств. Например, если у всех товаров надо добавить новое свойство, которое присуще всем товарам, то придется это свойство заводить в каждом инфоблоке отдельно, с парой инфоблоков еще можно справиться, но учитывать свойства десятка-другого инфоблоков уже слишком сложно. Плюсы: удобство редактирования товаров. Минусы: усложнение логики, неудобство управления раздельными инфоблоками, сложности при расширении ассортимента.
3. Предлагаемая архитектура В собственной реализации каталога товаров мы решили объединить плюсы обоих способов, исключив их минусы. Предлагаемая архитектура выглядит следующим образом:
Имеется один общий инфоблок с каталогом товаров - в нем хранятся основные данные товаров и общие свойства. Именно записи этого инфоблока являются товарами (имеют цены, описание, фотки, связи).
Характеристики товаров хранятся в отдельных инфоблоках. Каждый инфоблок отвечает за отдельный тип товара, например, ноутбуки. Свойства этого инфоблока - это характеристики для данного типа товаров. Они здесь описываются и хранятся.
Каждый товар связан со своими характеристиками значением специального свойства, в котором хранится ID записи с характеристиками. И каждая запись с характеристиками связана со своим товаром.
В инфоблоке "Каталог товаров" есть свойство "Тип товара" - это список инфоблоков заданного типа, которые и являются допустимыми типами товаров. При выборе значения из предложенного списка, на вкладке "Характеристики" подгружаются свойства выбранного инфоблока с характеристиками, т.е. характеристики, присущие данному типу товаров.
Тип товара также можно задать на раздел каталога товаров, при этом на любом уровне вложенности. Товары внутри такого раздела будут по умолчанию считаться с указанным типом.
Несмотря на кажущуюся сложность данной архитектуры, для пользователя всё выглядит просто и привычно. Основная сложность возникает для разработчиков - усложняется логика. Хотя старые компоненты можно использовать, но они будут полностью игнорировать привязанные характеристики товаров. Плюсы: удобство управления товарами и характеристиками, удобство развития ассортимента, удобство организации представления на сайте. Минусы: усложнение логики, необходимость использования новых компонентов Ниже приведено видео (0.98 Мб), демонстрирующее работу формы редактирования товара. При выборе типа товаров подгружается вкладка "Характеристики". Обратите внимание, что содержимое этой вкладки меняется в зависимости от выбранного товара.
Кто использовал такую архитектуру? Есть преимущества? Подскажите это реализовано штатными средствами Bitrix, можете описать как сделать подобное?
Если я правильно понял, на каждый товар придется заводить 2 элемента инфоблока - 1 для иблока "каталог товаров", другой для соответствующего иблока типа "характеристики товаров". С таким подходом проблем может быть масса, как минимум: фильтрация, импорт/экспорт, индексация модулем поиска
P.S. В битриксе на новом ядре должны эти проблемы со свойствами решить (на каждый раздел свой набор свойств).
You must have chaos within you to give birth to a dancing star. Friedrich Nietzsche