Господа, вот я тут размышляю, а какой профит использовать несколько инфоблоков?
По сути все элементы всех инфоблоков будут все равно в одной таблице. Разделы - тоже в одной таблице, но это не так критично.
Единственным плюсом появляется гипотетическая возможность хранить свойства в отдельной таблице для каждого инфоблока(2.0), но это часто тоже не решение.
Вот вынесли вы какую-то категорию товаров из общего каталога в отдельный инфоблок, она имеет 50 характеристик. (для электроники это вообще минимум). Вынесли свойства этого инфоблока в отдельную таблицу - и что? Ждать до тех пор, пока контентщики еще 50 свойств не запилят для раздела? А они это могут и делают быстро. И тут уже не факт, что не упрёмся в лимит MySQL и все будет работать как прежде. Горизонтально рост ограничен. А смысла делать отдельные инфоблоки и хранить свойства в общей таблице вообще нет никакого.
При этом разбивая каталог на разные инфоблоки, мы подписываемся на вечную доработку. Нужно добавить основной раздел? - Вперед, делайте инфоблок, подвязывайте его к выгрузке, к отображению в публичке и дальше по списку... Почему тогда 99% решений из маркетплейса, а также типовой магазин от Битрикса построен по принципу одного инфоблока с товарами? Потому что это удобно в рамках данной архитектуры системы. Добавьте еще к этому пляски с бубном со всеми штатными компонентами, которые нужно будет доделывать для мультиинфоблоковой работы.
Я вижу, что в данном случае, разбиение одного одного товароного каталога по разным инфоблокам - это просто попытка лечения кривой архитектуры, потому что "под капотом" изменений минимум, а дополнительной работы и проблем при этом непропорционально много.
В итоге получается, что мы просто кормим недоработку архитектуры битрикса, и его административной части в том числе.
Поправьте меня, если я не прав.
В таких случаях реально не хватает привязки свойств не к инфоблоку, а к разделу инфоблока с возможностью хранения в отдельной таблице. До сих пор не понимаю, почему это не реализовано - это бы решило все эти свистопляски и велосипедирования с кучей инфоблоков или вообще кастомной структурой хранения данных\модификацией административной части. Тем более можно же даже сейчас для смарт фильтра отбирать свойства для раздела с наследованием - почему не вынести эти свойства отдельно от общего инфоблока тогда? Сейчас очередной проект, где контентщики запилили 1500+ свойств. Под проект куплено готовое решение, естественно без поддержки работы на нескольких инфоблоках. Также выгрузка штатная из 1С тоже работает с 1 инфоблоком, как и все базовые компоненты. Причем свойства специфичны именно для каждого конкретного раздела каталога, общих свойств для всех товаров штук 5.
Может, я не прав, но подскажите тогда нормальное адекватное решение без велосипедов и отдельных инфоблоков?
По сути все элементы всех инфоблоков будут все равно в одной таблице. Разделы - тоже в одной таблице, но это не так критично.
Единственным плюсом появляется гипотетическая возможность хранить свойства в отдельной таблице для каждого инфоблока(2.0), но это часто тоже не решение.
Вот вынесли вы какую-то категорию товаров из общего каталога в отдельный инфоблок, она имеет 50 характеристик. (для электроники это вообще минимум). Вынесли свойства этого инфоблока в отдельную таблицу - и что? Ждать до тех пор, пока контентщики еще 50 свойств не запилят для раздела? А они это могут и делают быстро. И тут уже не факт, что не упрёмся в лимит MySQL и все будет работать как прежде. Горизонтально рост ограничен. А смысла делать отдельные инфоблоки и хранить свойства в общей таблице вообще нет никакого.
При этом разбивая каталог на разные инфоблоки, мы подписываемся на вечную доработку. Нужно добавить основной раздел? - Вперед, делайте инфоблок, подвязывайте его к выгрузке, к отображению в публичке и дальше по списку... Почему тогда 99% решений из маркетплейса, а также типовой магазин от Битрикса построен по принципу одного инфоблока с товарами? Потому что это удобно в рамках данной архитектуры системы. Добавьте еще к этому пляски с бубном со всеми штатными компонентами, которые нужно будет доделывать для мультиинфоблоковой работы.
Я вижу, что в данном случае, разбиение одного одного товароного каталога по разным инфоблокам - это просто попытка лечения кривой архитектуры, потому что "под капотом" изменений минимум, а дополнительной работы и проблем при этом непропорционально много.
В итоге получается, что мы просто кормим недоработку архитектуры битрикса, и его административной части в том числе.
Поправьте меня, если я не прав.
В таких случаях реально не хватает привязки свойств не к инфоблоку, а к разделу инфоблока с возможностью хранения в отдельной таблице. До сих пор не понимаю, почему это не реализовано - это бы решило все эти свистопляски и велосипедирования с кучей инфоблоков или вообще кастомной структурой хранения данных\модификацией административной части. Тем более можно же даже сейчас для смарт фильтра отбирать свойства для раздела с наследованием - почему не вынести эти свойства отдельно от общего инфоблока тогда? Сейчас очередной проект, где контентщики запилили 1500+ свойств. Под проект куплено готовое решение, естественно без поддержки работы на нескольких инфоблоках. Также выгрузка штатная из 1С тоже работает с 1 инфоблоком, как и все базовые компоненты. Причем свойства специфичны именно для каждого конкретного раздела каталога, общих свойств для всех товаров штук 5.
Может, я не прав, но подскажите тогда нормальное адекватное решение без велосипедов и отдельных инфоблоков?