Внедряю БСП и столкнулся со странным на мой взгляд требованием:

Для каждого типа объекта для которого я хочу хранить прикрепленные файлы требуется заводить отдельный справочник вида <Префикс>ПрисоединенныеФайлы.

Мне нужно для 9 справочников хранить прикрепленные файлы, получается я должен сделать 9 одинаковых справочников <Префикс>ПрисоединенныеФайлы

Вот хотел бы обсудить, может как то по другому можно, ну и вообще хотелось бы понять почему разработчики БСП пошли по такому странному пути.

p.s. Я понимаю что можно использовать подсистему Работа с файлами, но на мой взгляд она тяжела для "просто хранить приложенные файлы" и больше подходит для совместной работы и редактирования файлов.

Зачем для каждого? Что-то не то Вы делаете.

Справочник Файлы, реквизит ВладелецФайла - туда запихать Ваш справочник.

Команда ПрисоединенныеФайлы - туда тоже в параметры команды.

И вроде все. Но может чего забыл - давно не брал шашку в руки.

ну типа что бы в файловом варианте дольше времени не перемахнуть в 4 гига на таблицу.

(3)  откуда 4гига?

Был дикий срач с тролингом, выяснили что для РЛСа все

(0) да, для каждого объекта свой справочник ПрисоединенныеФайлы. по мне так правильнее, чем 1 справочник для всех объектов  с файлами.

(6) может тогда пора вернуть отдельный справочник для номенклатуры и материалов? А так же не забыть контрагентов - разделить покупателей и поставщиков

(7) если тебе так нравится, то можешь делать, я не против

(3) какие 4 гига если там хранятся в рабочем режиме только пути к файлам ?

(7) а что не нравится в таком подходе? может есть какие то проблемы о которых я не знаю? а с одним справочником, например как в ут 10.3 ХранилищеДополнительнойИнформации, например были проблемы с настройкой прав к этому справочнику.

(7) есть 2 подсистемы:

одна на справочниках - для РЛС - проталкивается "по умолчанию"
вторая - в общем справочнике и регистре - по умолчанию отключена  но в ней есть версионирование файлов.

(10) он видимо любитель делать всю конфигурацию на одном справочнике..
и на одном документе

чтобы облегчить rls'ы и прочие однояйцевые дескрипотры

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

(12) Я за декомпозицию отдельными руками но тогда когда это обусловлено здравым смыслом, все таки декомпозиция и копипаста это немного разные вещи.

(13), (5) Да похоже для РЛС, будем надеяться что эти справочники не будут часто изменятся и не придется каждый раз каждый из низ отдельно менять.

(11) 2я подсистема РаботаСФайлами? Если да то он предназначена именно для работы с файлами, и значительно тяжелее, использовать её для хранения прикрепленных файлов совсем не вариант.
И на мой взгляд РЛС там значительно тяжелее.

(1),(2) увы так не получится, это первое что я попробовал.

Спасибо всем за информацию, хотя бы легче стало от того что есть понимание зачем так сделано.

(14) >будем надеяться что эти справочники не будут часто изменятся
Чего ты там часто менять собрался? Там полтора реквизита...

(15) я  ничего, а вот 1С запросто, реквизитов там 19 + 2 ТЧ 8 и 3 реквизита итого 30 реквизитов.  

Если кому еше интересно то в "ПрисоединенныеФайлыПереопределяемый"
Есть процедура:

// Позволяет переопределить справочники хранения файлов по типам владельцев.
//
// Параметры:
//  ТипВладелецФайла  - Тип ссылки объекта, к которому добавляется файл.
//
//  ИменаСправочников - Соответствие, содержащее в ключах имена справочников.
//                      При вызове содержит имя одного стандартного справочника.
//                      Если в значении соответствия разместить Истина только
//                      один раз, тогда в случаях, когда требуется один справочник,
//                      будет выбран такой справочник.
//                      Если же справочников несколько, и не один в значении не содержит
//                      Истина или более одного содержат Истина, тогда будет ошибка.
//
Процедура ПриОпределенииСправочниковХраненияФайлов(ТипВладелецФайла, ИменаСправочников) Экспорт

В ней можно анализировать тип владельца и подставлять тот или иной справочник.

Но вообще чем больше я узнаю БСП тем меньше она мне нравится, очень слабая настраиваемость, очень много "хардкода".
У меня есть мысль что я чего то не понимаю в этой системе, но чем дальше тем меньше я в это верю.
Вот пример по теме:

В демо (шаблоне) справочнике <Идентификатор>ПрисоедененныеФайлы есть набор реквизитов, при этом на форме "ПрисоединенныйФайл" реквизитов нет вообще, они добавляются обработчиком:

&НаСервере
Процедура СоздатьЭлементыФормы()
    
    Элемент = ДобавитьПолеОбъектаНаФорму(
        "Наименование", Элементы.ГруппаОбщаяИнформация, Истина, "Имя файла", Ложь);
    
    Элемент = ДобавитьПолеОбъектаНаФорму(
        "Описание",     Элементы.ГруппаОбщаяИнформация, Истина,            , Ложь);

    ДобавитьПолеОбъектаНаФорму("Автор",       Элементы.ГруппаСведенияЧасть1);
    ДобавитьПолеОбъектаНаФорму("Изменил",     Элементы.ГруппаСведенияЧасть1);
    ДобавитьПолеОбъектаНаФорму("Расширение",  Элементы.ГруппаСведенияЧасть1);
    ДобавитьПолеОбъектаНаФорму("Редактирует", Элементы.ГруппаСведенияЧасть1);
    
    ДобавитьПолеОбъектаНаФорму("ДатаСоздания", Элементы.ГруппаСведенияЧасть2, , , , Ложь);
    ДобавитьПолеНаФорму("ДатаМодификации",     Элементы.ГруппаСведенияЧасть2);
    ДобавитьПолеОбъектаНаФорму("Размер",       Элементы.ГруппаСведенияЧасть2, , , ,     , 11);
    
КонецПроцедуры


Казалось бы отличное, правильное решение, разработчик может смело добавить свои реквизиты в Спр.<Идентификатор>ПрисоедененныеФайлы и описать их в этой процедуре.

Но проблема в том что при обновлении подсистемы об этом нужно будет помнить. Т.е. с одной стороны видно что закладывали универсальность, с другой стороны универсальности нет, правильнее было бы сделать в переопределяемом модуле Функцию типа "ПолучитьТаблицуРеквизитов" и по этой таблице в цикле заполнять форму реквизитами.

Или например использовать ПрефиксыИмен реквизитов (такой подход используется в БСП но я не одобряю).

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

(16) ты как будто ищешь где бы подкопаться. я вот один раз настроил и забыл, все прекрасно работает и обновляется. если тебе не устраивает из БСП, пиши свой справочник, никто не заставляет использовать БСП.

(17) Собственно говоря про "Настроил" и речь, я привел пример когда настроить нельзя, только править код, если править код то будут проблемы с обновлением. Я привел только пример уместный в контексте обсуждаемого вопроса, таких примеров у меня с десяток уже набрался, и везде примерно одно и тоже: архитектура позволяет делать гибкие настройки, но косяки в реализации убивают всю задумку.

В любом случае времени потраченного на БСП не жаль потому что есть чему поучится, многие решения выглядят очень изящно.