Имя: Пароль:
1C
1С v8
В каком формате лучше хранить внешние данные?
0 al_zzz
 
17.01.22
10:27
Поставили следующую задачу: требуется организовать обмен с внешней системой. Текущую конфигурацию изменять нельзя, а мне требуется для обмена добавлять свои справочники. Заказчик предлагает такие внешние вещи хранить не в базе, а в файлах на диске.
Сколько может возникнуть таких внешних сущностей и в них записей заранее не известно. Лучше считать, что много.
Думал задействовать для каждой сущности ЗначениеВФайл/ЗначениеИзФайла. Просто помещать тз в файлы и читать при необходимости.
Какие есть ограничения на размеры таким образом сформированных файлов? Чем эффективнее воспользоваться вместо данного механизма?
Заранее спасибо!
1 Ёпрст
 
17.01.22
10:30
(0) любая табличка, подключенная через ВИД, на крайняк, база на скульлайте/компакт sql
2 Ёпрст
 
17.01.22
10:31
Ну и это, расширения пользуй и пихай туда свои объекты, это еще проще.
3 Dmitrii
 
гуру
17.01.22
10:39
(0) >> Текущую конфигурацию изменять нельзя.

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

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

Можно запилить свою конфигурацию на БСП с подсистемами обменов. В этой бае хранить УИДы ключевых данных основной базы.
Ну или базу данных в каком-либо стороннем формате, как рекомендует (1).
4 al_zzz
 
17.01.22
10:46
(3) Мешает то, что это обычный интерфейс. Скулайт - вариант.
5 pechkin
 
17.01.22
10:48
(4) лучше тогда нормальную бд. если конечно у вас не файловый вариант
6 banco
 
17.01.22
10:51
(4) А при чем тут обычный интерфейс и расширение?
7 fisher
 
17.01.22
10:56
(0) Тут достаточно широкое поле решений. Зависит от специфики "внешней системы" и обмена с ней. Бывает, можно обойтись доп-реквизитами. Бывает, можно нужные служебные таблички держать на стороне "внешней системы". В любом случае, заводить для этого "отдельное место" - это наихудшее решение из возможных.
8 fisher
 
17.01.22
11:00
Хотя вру. Можно придумать случаи, когда отдельная база будет оптимальным вариантом.
9 Кирпич
 
17.01.22
11:03
(0) ну создай конфу с парой справочников и храни в ней
10 pechkin
 
17.01.22
11:05
(8) какое нибудь версионирование вполне лучше держать на отдельной базе
11 al_zzz
 
17.01.22
11:20
Режим совместимости = 8.2.
Отдельную конфу не хотелось бы, так как долго подключаться к ней.
12 Garykom
 
гуру
17.01.22
11:20
(0) Банально начать с табдоков в виде файликов экселя
Там есть НайтиЗначение и НайтиТекст

В ёкселе удобно для человеков если что смотреть
Не будет хватать скорости перейти на DBF (XBase) например
13 Garykom
 
гуру
17.01.22
11:21
(11) Не надо COM/OLE юзать, надо HTTP
Но есть трабла с публикацией согласен
14 NorthWind
 
17.01.22
11:23
(0) хмл или жсон можно.
15 Garykom
 
гуру
17.01.22
11:24
(14) Для базы данных это не очень решение в отличие от обмена
16 al_zzz
 
17.01.22
11:26
(13) Нет, не вариант с HTTP. Там много распределенных и для каждой распределенной надо будет повторить. Ну или какой-то сервис, чтоб сразу из разных баз подключаться.
17 al_zzz
 
17.01.22
11:27
Конфигурация 1С-Рарус: ТКПТ v8 (08.1.37.01). Мне в ней разрешили только план обмена завести.
18 Garykom
 
гуру
17.01.22
11:33
(16) Ну так и сделай (микро)сервис
Поднимаешь его в одном месте и из всех РИБ обращаешься по HTTP
И да весь обмен-синхронизация на нем же, из ТКПТ только запросы по HTTP с УИДами
19 Кирпич
 
17.01.22
11:35
(11) "так как долго подключаться к ней"
Ты попробуй сначала подключиться. Это же не типовая будет. Типовая долго открывается. А твоя будет мгновенно
20 al_zzz
 
17.01.22
11:38
(19) Попробую. Спасибо!
(18) Вероятно, этот вариант не подойдёт. Клиент хотел максимально автономно чтоб узлы работали.