Добрый день.
Чем плох менеджер в плане производительности при записи одной или нескольких строк?

(0) При записи нескольких строк плох тем, что не может записать несколько строк.

технически, при записи набора, сервер приложений записывает каждую строку по отдельности - да - так, же, как он делает при записи менеджером записи. Но при записи набора он это делает в одной транзакции. При записи туевой хучи менеджеров будет туева хуча транзакций.

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

(3) да щас!

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

(2) >записывает каждую строку по отдельности
Трассировка это подтверждает? Я не проверял, но уверен, что там один INSERT/UPDATE и массив параметров.

Насчет транзакций, никто не мешает записывать менеджером записи в одной транзакции.

(2) зато в начале набор одним запросом сначала очищает записи

а в транзакцию можно и насильно обернуть

(5) в цикле легко )))

(6) "Я не проверял, но уверен" - ага

(9) Никогда такого не было, и вот - опять )))

https://its.1c.ru/db/pubdevguide#content:595:hdoc
https://its.1c.ru/db/pubdevguide#content:596:hdoc

(9) Да, я поторопился с выводами. Если подумать, то в наборе записей всегда есть отбор, поэтому не массив параметров, а WHERE. Но уверенность в том, что не "каждую строку по отдельности", остается. Какой смысл ставить очевидный барьер производительности?

(12) а как будет выглядеть этот запрос, например, при записи набора из 1000 строк?

(4) Он правду говорит.

(12) Смысл в Error: 10739, Severity 15, The number of row value expressions in the INSERT statement exceeds the maximum allowed number of 1000 row values.

(14) что производительность одинаковая - враньё!

(12) РегистрыСведений.КонтактнаяИнформация.СоздатьНаборЗаписей().Записать()

какой здесь отбор всегда есть?

(17) Естественный (:

(17) Здесь отбор на тех, кто свой код тестит на копии и смотрит в результат или не тестит и потом ищет бэкапы.

(15) Для INSERT скорее всего массив параметров. Для UPDATE, DELETE отбор.

(17) Если отбор не установлен, значит будет DELETE без отбора, то есть на весь регистр.

Я имел в виду, что набор обрабатываемых строк всегда можно идентифицировать отбором.

(20) "Для INSERT скорее всего массив параметров. Для UPDATE, DELETE отбор."

ты несешь какую-то дичь

(21) Возможно. Просвети, как на самом деле.

При сохранении информации при использовании в программном коде объекта МенеджерЗаписи Платформа сама создает объект НаборЗаписей, а его уже записывает

(22) я уже писал:
1. один DELETE стирает все старые записи согласно отбора
2. куча INSERT где по одной записи вставляются новые

(24) А UPDATE как?

UPDATE не делается?

(25)(26) нет там никаких UPDATE

(24) Если "записать(ложь)", то delete нет, сразу поток insert

(28) согласен

Набор круче Менеджера только тем, что Delete делается 1 раз. Вот и все. Толпу менеджеров можно обернуть в
НачатьТранзакцию()
и ваш SDD будет жить спокойной жизнью.

Чет затихло, я думал тыщу постов наберет :)

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

(30) если есть подписки при записи/перед записью, то они в случае наобра также один раз отработают

(32) Огласи это единое мнение

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