Есть такая задача. В основной базе раздулся регистр Версии объектов (больше половины базы). Есть желание вынести его содержимое в отдельную базу и допилить модули/отчеты чтобы они брали недостающую инфу из нее. При этом иметь возможность периодически довыгружать содержимое регистра в эту базу. Каким инструментом лучше всего воспользоваться чтобы тянуть данные регистра из одной базы в другую? С обменами по большому счету работал только с COM, но говорят это медленно и старомодно, советуют Rest/ws, но там я так понял нужно будет описывать структуру данных. В общем что будет более применимо в данном случае?

(0) "раздулся регистр Версии объектов" там же можно настроить срок хранения версий. Если нужно что-то реально старое посмотреть, можно бекап развернуть

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

это ERP

(0) "советуют Rest/ws, но там я так понял нужно будет описывать структуру данных."
через НТТР-сервис в JSON.

(4) тоже пока в эту сторону смотрю

мне просто интересно, зачем хранить версию объекта 3х летней давности к примеру? Ну узнаете вы кто в заявке количество поправил в 50ой строчке, а дальше что?) Человек уже может не работать в конторе, поправить задним числом документ тоже вряд ли получится (привет закрытие месяца) и т.д. Зачем забивать базу такими версиями объектов?

(6) В крупной конторе такая фишка требовалась ну раз в год,чтобы посмотреть что-то старше года

(6) просто в последнее время регистрацию изменений стали для всего включать, а он и так раздулся, еще помимо документов там НСИ и спецификации

+ примерно год назад мы его все-таки сократили. Опыт показал что информация старше года все-таки востребована, и объем с этого времени тоже приличный набежал

+ за неоправданность цели по сравнению с расходом ресурсов.
(8) отговаривать до последнего, если не получается - бить

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

кстати по теме интересный вопрос - если сделать отдельную базу для хранения версий объектов, в ней же все эти объекты должны будут существовать, чтобы версии в регистр проставить. Как, переносом из живой базы? получится точная копия источника, нет?

Идея конечно интересная. Но единственная задача, которую вы при этом решите - уменьшение объёма регулярных бекапов продуктива.
Суммарный объём двух баз (продуктив + БД с историей версий) не уменьшится.
Стоит ли оно того при нынешней цене дискового пространства?

ну вернее все те типы, которые на версионировании находятся, но один хрен, если включают для всего подряд

+ ко всему, из 1 звена вы получаете как минимум 2. Вам придется бекапить базу с версиями, а так же следить, чтобы синхронизация выполнялась и не было косяков с обменом.

а обмен - легко, СериализаторXDTO + ЧтениеXML/ЗаписьXML между идентичными базами справятся в совсем немного строчек кода

ну и плюс сервис конечно, куда же без них сейчас
(15) да муть конечно, но бывает надо. правда доказать что надо и одно и другое и пятое - дело тоже не простое, обычно большинство таких "нужностей" только на словах пользователей, на самом деле - это выяснение отношений между этими самыми пользователями. Кто когда и что поставил, почему поменял задним числом и остальное.
(0) Скажите им, что не хотите участвовать в их поисках виноватых, потому что сами боитесь им стать.

чуть отстал, json сейчас модно

(13) так версии можно не бекапить. Пропадут - ну и х с ними

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

(20) кому-то нужны, но думаю это не особо критично для бизнеса.

Ладно с бекапами, но в больших отделах разработку каждому разрабу нужна своя база, и не одна, возможно, + естедей базы - вот тут точно версии не нужны

(20) да хоть и без версий база

почитал про жсон.. он что непримитивные типы сериализовать не умеет что ли? так что бы потом прочитать() и у тебя готовая ТЗ в переменной

умеет, но через xdto, те же яица, но в профиль. кажется понятно, почему он нах не нужен.

А чем ВИД не вариант?

И как собираешься структурную целостность обеспечивать? Т.е. когда в источнике физически удалили объект-владелец этих данных

Есть обработчик версий,в котором версию можно засовывать в другую базу в том виде,как она есть и базу даже не 1с.
Плюс еще можно сегментирование делать по времени,чтобы бэкапы были легче.
И для версии никакая целостность не нужна - нужна только иныормация,что поменялось.