Поставили следующую задачу: требуется организовать обмен с внешней системой. Текущую конфигурацию изменять нельзя, а мне требуется для обмена добавлять свои справочники. Заказчик предлагает такие внешние вещи хранить не в базе, а в файлах на диске.
Сколько может возникнуть таких внешних сущностей и в них записей заранее не известно. Лучше считать, что много.
Думал задействовать для каждой сущности ЗначениеВФайл/ЗначениеИзФайла. Просто помещать тз в файлы и читать при необходимости.
Какие есть ограничения на размеры таким образом сформированных файлов? Чем эффективнее воспользоваться вместо данного механизма?
Заранее спасибо!

(0) любая табличка, подключенная через ВИД, на крайняк, база на скульлайте/компакт sql

Ну и это, расширения пользуй и пихай туда свои объекты, это еще проще.

(0) >> Текущую конфигурацию изменять нельзя.

Идиотское ограничение. В особенности для случаев, когда все добавляемые объекты (справочники, регистры и т.п.) добавляются что называется "сбоку", без вмешательства в типовые объекты.

Даже если убедить заказчика не удаётся, то что мешает воспользоваться для этого расширениями.

Можно запилить свою конфигурацию на БСП с подсистемами обменов. В этой бае хранить УИДы ключевых данных основной базы.
Ну или базу данных в каком-либо стороннем формате, как рекомендует (1).

(3) Мешает то, что это обычный интерфейс. Скулайт - вариант.

(4) лучше тогда нормальную бд. если конечно у вас не файловый вариант

(4) А при чем тут обычный интерфейс и расширение?

(0) Тут достаточно широкое поле решений. Зависит от специфики "внешней системы" и обмена с ней. Бывает, можно обойтись доп-реквизитами. Бывает, можно нужные служебные таблички держать на стороне "внешней системы". В любом случае, заводить для этого "отдельное место" - это наихудшее решение из возможных.

Хотя вру. Можно придумать случаи, когда отдельная база будет оптимальным вариантом.

(0) ну создай конфу с парой справочников и храни в ней

(8) какое нибудь версионирование вполне лучше держать на отдельной базе

Режим совместимости = 8.2.
Отдельную конфу не хотелось бы, так как долго подключаться к ней.

(0) Банально начать с табдоков в виде файликов экселя
Там есть НайтиЗначение и НайтиТекст

В ёкселе удобно для человеков если что смотреть
Не будет хватать скорости перейти на DBF (XBase) например

(11) Не надо COM/OLE юзать, надо HTTP
Но есть трабла с публикацией согласен

(0) хмл или жсон можно.

(14) Для базы данных это не очень решение в отличие от обмена

(13) Нет, не вариант с HTTP. Там много распределенных и для каждой распределенной надо будет повторить. Ну или какой-то сервис, чтоб сразу из разных баз подключаться.

Конфигурация 1С-Рарус: ТКПТ v8 (08.1.37.01). Мне в ней разрешили только план обмена завести.

(16) Ну так и сделай (микро)сервис
Поднимаешь его в одном месте и из всех РИБ обращаешься по HTTP
И да весь обмен-синхронизация на нем же, из ТКПТ только запросы по HTTP с УИДами

(11) "так как долго подключаться к ней"
Ты попробуй сначала подключиться. Это же не типовая будет. Типовая долго открывается. А твоя будет мгновенно

(19) Попробую. Спасибо!
(18) Вероятно, этот вариант не подойдёт. Клиент хотел максимально автономно чтоб узлы работали.