|
В каком формате лучше хранить внешние данные? | ☑ | ||
---|---|---|---|---|
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) Вероятно, этот вариант не подойдёт. Клиент хотел максимально автономно чтоб узлы работали. |
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |