Форум

[QUOTE]alexshow пишет:
Но позже выяснилось, что функционал тегирования работает через компонент поиск и ведет на страницу поиска где выводит соответствующий поисковый результат. Вопрос состоит в том, что придется копать в сторону свойств элемента? Программировать специфические фильтры для каждого раздела?[/QUOTE]
необходимо правильно настроить шаблоны ссылок на элементы и разделы инфоблоков (в настройках инфоблоков)
с учетом разделов, в которых блокибудут находиться (именно они используются модулем поиска)

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

Скажу вам так
если хочется возиться с разнообразием свойств в одном каталоге
(поверьте возни будет порядочно хотя и по мелочам. особенно в публичке)

сам несколько таких решений делал (с гибким управлением свойствами) и это далеко не айс
поэтому поддерживаю ваш вариант реализации с разделением именно на несколько инфоблоков

как свести?
все достаточно просто
если есть желание - можно каждый блок разместить в отдельном разделе (в том числе можно использовать и комплексный компонент каталог) например #My-Site/store/photo/
а уж свести то их - в чем именно проблема?
написать список инфоблоков с ссылками на них на одной из страниц (например #My-Site/store/ ) и все

более гибкий вариант - размещение комплексного компонента каталога в одном разделе
и динамическое формирование его параметров: иблок, свойства, фильтр и пр. в зависимости от вида обращения (например по переменой в которой стоит код инфоблока)

первый вариант менее муторный, так как все вроде типовое и никаких затыков не предвидится. Если инфоблоков немного, то он удобнее

второй вариант требует более серьезных размышлений и раздумий и, возможно, небольших доработок

можно и инфоблоками ;)
только учтите, что некоторые поля у вас пойдут свойствами (а это еще табличка :) если используем ИБ +)
также надо учесть предполагаемый объем обрабатываемых записей
и может получиться, что использование собственных таблиц даст вам большее преимущество в работе (производительности), чем использование API работы с инфоблоками.
плюс я молчу про объемы БД в том и др. случаях.

поэтому прикиньте лучше для начала ваши объемы.
Тогда и сделаете вывод для себя. Какой способ более оптимален.

в том числе обратите внимание на кого зарегистрирован продукт
(раз такой случай)

http://ваш сайт/bitrix/admin/sysupdate.php?lang=ru

внизу информация по вашей лицензии

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

пока могу высказть только такие предположения:
если у вас обмен полный и ежедневный, а данные в старой базе остались еще из прошлой выгрузки (т.е. данные по результатам прошлого обмена) то "связь с картинками" теоретически могла нарушиться
[QUOTE]sergdi пишет:
Снова загрузили из 1С. Часть фото появилась, а часть товаров вообще
не обновляется и фото не создаются.[/QUOTE]
в каком режиме обмена?
если в полном - то затрудняюсь ответить, надо смотреть, если в режиме изменения - теоретически такое возможно

И еще момент
БД точно прошлого дня? Это уже проверено?

В данном случае лучше обратиться к документации
http://dev.1c-bitrix.ru/api_help/iblock/index.php

обратите внимание на понятия поля и свойства

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

однако на типовых компонентах такого наблюдаться не должно

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

а после переиндексации информация о странице в b_search_content точно не появилась?

забыл упомянуть еще момент - производительность БД
низкая производительность может свести на "нет" все быстродействие

в общем лучше начать с анализа производительности сервера а потом уже решать с правами на доработку