Как известно, планы обмена заточены под работу через БСП и с количеством узлов обмена более 2х. В случае если в интегрируемой конфигурации всего два узла и нет БСП, мне видится более оптимальным решение задачи регистрации ссылочных объектов к обмену через независимый непериодический регистр сведений.
Интересно мнение экспертов в области быстродействия.

При чтении кандидатов к выгрузке из регистра будешь его блокировать?

Первое: Планы обмена работали уже тогда, когда ещё не было БСП - что принципиального изменилось сейчас? Ссылка на БСП тут совсем "не при делах".

Второе: планы обмена работали уже тогда, когда их ещё не было в типовых конфигурациях :) Парадокс? Отнюдь нет. План обмена - это механизм платформы. Хочешь программно(!) работать быстрее платформы? :))

(1) Для операции чтения наложение исключительной блокировки не требуется
(2) В БСП это тоже осуществляется программно в соответствующих обработчиках "ПередЗаписью". К тому же при этом используются ПРО, а это накладные расходы. Я же все проверки о необходимости такой регистрации планирую реализовать в коде в тех же обработчиках.

+Если бы не думал, что регистры сведений реально легче, не было бы и темы.

(3) ну и чем тогда регистр лучше? делай то же самое через план обмена и будет тебе счастье.

(3) и (4) Это всё равно не объясняет желание использовать независимый непериодический регистр сведений. Таблицы регистрации быстрее - они пишутся одновременно с объектом а не отдельно от него (как в случае с РС).

(офф) Имхо, удивительно, как платформа может быстро лопатить данные, когда ей не мешает конфигурация :)

(3) Ну ладно тебе, не придирайся :) При завершении чтения-выгрузки (для обновления признака, что объекты БД выгружены) будешь блокировать регистр?

(2) в случае с авторегистрацией быть может вы и правы, но авторегистрация не катит.
(5) подход делать так потому что так делают все и давно?)))

(7) все просто. при завершении выгрузки регистр будет очищаться. для конкретной задачи этого достаточно.

(7)+ а чем страшна эта блокировка в нерабочее время?

(8) ну просто через регистр вообще это еще надо ведь писать. Это например 10000 строк кода тебе нужно самому написать. Там сотни разных нюансов, которые тебе сейчас не видны, но с которыми ты тут же столкнешься, как только начнешь. А через планы обмена всё давно написано.

(9) Я говорил хоть слово про авторегистрацию? Я хотел лишь напомнить, что таблица регистрации - это таблица самого объекта. Такая же как реквизиты и табличные части самого объекта. Принцип работы платформы с регистрацией изменений другой, ок?

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

(0) быстрее всего пишется регистрации на узлах в планах обемена, при записи нет контроля уникальности значений

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

(13) спалился

"Интересно мнение экспертов в области быстродействия"
PS.
"планы обмена заточены под работу через БСП" - нет, это заблуждение.
"с количеством узлов обмена более 2х" - нет, это тоже спорное утверждение.

"мне видится более оптимальным решение задачи" - без комментариев. Sorry, но доказательств обратного - не будет. Вы хотели услышать мнение - своё мнение я озвучил.

(12) С авторегистрацией операция может выполнятся в месте с записью, без для этого используется обработчик, а это исполнение кода 1с. Как это может быть одновременно?

(17) утверждение выше следует понимать как БСП используется для упрощения работы с планами и оправдывает использование последних в решении. Без БСП не вижу большого смысла в использовании планов.
По узлам - наличие узлов усложняют работу по регистрации/очистке. не боле.

(0) Гм. Оба исходных данные не верны. О чем можно спорить?

(9) Так у тебя обмен односторонний, выходит, и без гарантии доставки. Еще и в нерабочее время? Тогда через планы обмена сам бог велел

(20) я не хочу спорить. хочу аргументы.
(21) Односторонний. Вы религиозный человек?

"Без БСП не вижу большого смысла в использовании планов" // Большой смысл в накоплении (регистрации) изменений. И не нужно писать код.
"наличие узлов усложняют работу по регистрации/очистке. не боле" // См. (16)

(22) зачем тебе аргументы. Раз решил через регистры, делай.

(23) запись в рс это пара тройка строк кода.
а что смотреть в (16)?

(22) Да, Вы правы. Он ошибся с термином.
Не "односторонний" - а "неполноценный и неработоспособный" :))

Что будет в случаи неполучения сообщения обмена по какой-то причине? Регистрация Вами очищена. Нужен механизм подтверждения получения и успешной обработки в узле-приёмнике.

(25) удаление документа как будешь отмечать в своем регистре?

(26) А вот что будет: комулятивный апдейт периодически - это раз. удаление регистрации при получении сообщения об отработке загрузки по крайней мере без ошибок - это два.

(27) такая задача не стоит.

(28) "А вот что будет... раз... два..." - давай сразу "три" и закончим об этом: "я пишу свой альтернативный велосипед вместо внутриплатформенного механизма плана обмена".

(29) ну встанет, и будешь что тогда со своим быдлокодом делать?

(26) А может ему не нужен "механизм подтверждения получения и успешной обработки в узле-приёмнике"? Ну например. Вполгн достаточно одностороннего обмена.

Вот в семерке не было планов обмена. И служба регистрации была достаточно примитивной. Не позволяла в коде фильтровать получателей. Пришлось пилить свою. На справочнике. Если на "той стороне" чего не получали (квитирования не было) - звонили менеджеру в центр и он добавлял нужное к отправке.

ЗЫ. Но более удобный вариант чем использование планов обмена у ТС вряд ли получится. Вся аргументация в (13) " работа с регистрами сведений мне намного привычнее." - попытка оправдать свою некомпетентность. Вместо того, что бы изучить работу с планами обмена.

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

Полемикой можно заниматься сколь угодно бесконечно.
Решение задачи в общем виде не всегда целесообразно (квитирование, множество узлов, удалениеобъекта). Задачу можно и нужно упрощать.
РС простейшая сущность стало быть и работать должен быстрее.
Более того, у меня есть подозрение, что включение регистрации объектов в планах скорее всего еще и будет тормозить саму запись этих объектов...
Для ответа на вопрос нужен замер производительности.
Утверждать обратное как минимум не дальновидно.

Я, наверное, оставлю без ответа вопросы в (32) и утверждения в (34). Иначе мы договоримся до того, что автор сознательно отказывается и нарушает основные принципы поддержания целостности и взаимной непротиворечивости данных информационной базы.

(35) А я еще раз спрошу.)))
Ну вот если я делаю выгрузку на сайт. Допустим. И не владею методами работы с планами обмена. Допустим. Что мне выбрать?

ЗЫ. Лично я бы выбрал планы обмена. Потому что на них шишек набил уже не одну. Но если ТС не умеет их готовить - РС вполне себе подходящий инструмент.

ЗЫЗЫ. За поддержание "целостности и тем более непротиворечивости" в случае обмена с сайтом или любой другой посторонней БД речь скорее всего не идет.

(36) Насколько я понял тему автора - речь не об обмене с сайтом.

Я понимаю на что Вы намекаете :) Мол, при работе с сайтом "не всё так однозначно"(цы).

А теперь представьте сайт на котором можно оформить и оплатить заказ покупателя... :) Покупатель оплатил заказ и имеет право требовать его исполнения со всеми вытекающими из этого. Вот теперь ещё раз мне скажите, что пр обмене с сайтом "не принципиально" всё выше сказанное в теме :))

Использование планов обмена не заставляет использовать сообщения обмена.
а весь косяк именно в соощениях

Согласен. При постоянном и надёжном онлайне можно читать регистрацию базы-источника непосредственно в базе-приёмнике и импортировать нужные данные. При оффлайне этосложнее организовать :)

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

(40) и что? пусть работают

(41) Sorry, Ваш вопрос я оставлю без ответа. Это всё "Флейм и оффтопик" и к теме автора (напомню: который хочет отказаться от регистрации изменений в пользу РС) не относится.

Вообщето в высоконагруженных системах как раз и отказываются от типовой таблицы изменений в пользу РС. А причина банальная. У таблицы изменений нельзя наложить управляемую блокировку.

На моей практики в типовой БП при включения стандартного плана обмена при закрытии квартала и групповом перепроведении параллельно разными бухами по разным организациям наблюдаются блокировки и чем дольше небыло обмена (чем больше данных в таблице изменений), тем блокировки чаще. (P.S> последний раз правда это было на платформе 8.2, как на 8.3 не знаю, ибо с переходом на БП 3.0 отказался от УРИБ и планов обменов в пользу единой базы).

По сути таблица изменений для каждого объекта одна общая и блокируется полностью, а вот конкуренция на запись туда не маленькая. Это и сами пользователи и обмены (при отправки туда пишется номер пакета, а при записи чистятся полученные)
Т.е.

Вообще немного по теме можно глянуть тут https://forum.infostart.ru/forum15/topic185103/

(43) Я полностью согласен с Вами относительно высоконагруженных систем. Но автор об этом ничего не сообщал.
(44) Я бы ещё порекомендовал, например, http://expert.chistov.pro/public/561460/

Хочу уточнить: я не против, если автор желает полностью отказать от использования плана обмена в определенном конкретном случае. Да, при определенных условиях (и если автор совершенно уверен, что они не изменятся со временем) в частном случае можно отдать предпочтение РС как альтернативе. Ему виднее.

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

(45) Зачем ты ссылку на ИС заменил на чистовскую?

(46) Это к ВР инфостарта. Расплодил клонов....

Просто в яндексе ввел строку поиска и неглядя дал первую ссылку из яндекса

(0)всё не читал,
используйте план обмена, а там как вам больше нравится через БСП или как-то иначе, это дело вкуса

(43) Благодарю за развернутый ответ по существу, да еще и со ссылками!!!

(2) А Вы быстро свое мнение меняете)

(46) Во первых, я не "заменил", а "дополнил" - я сказал "ещё" :) Во-вторых: в ссылке Инфостарта тема начинается от "как всем известно"(цы). Я не раз убеждался что многим это, увы, не известно. В ссылке на Чистова рассмотрена сама структура таблиц регистрации изменений и работа платформы с ними.

(49) Я не меняю своё мнение, я остаюсь при нём. Я предлагаю Вам флаг в руки, барабанные палочки и вперед по шпалам навстречу электричке :))

А если без шуток, то почему Вам действительно не попытаться самом реализовать "более оптимальное решение задачи"? Я предупредил, Вы - услышали. Моя задача выполнена.

(офф)
Тема про указанные ссылки - сама по себе интересная и достойна отдельного обсуждения.
Так, например, по ссылке Инфостарта https://forum.infostart.ru/forum15/topic185103/ в четвертом посту к обсуждению подключается http://catalog.mista.ru/profile/525991/ и приводит несколько ссылок на свои публикации. В частности публикацию http://catalog.mista.ru/public/561460/ ...

(50) Походу не понял мой вопрос

Ааа... ты об этом :( Угу, в этом смысле - да, заменил. Сам знаешь почему.

Кто и почему грохнули сообщения про мистаскрипт и подмену ссылок?

Правило №2 "Флейм и оффтопик в тематических разделах 1С и IT не допускается."