Ну сейчас после закрытия манифестао может и вывезут. Но не раньше чем через год :) Хотя для номадов в среднем все же не все так мрачно всегда было. Особенно с учетом того, что условия очень лайтовые. По сути выписка из банка, рабочий договор, договор аренды и справка о несудимости из основных документов.
я не знаю, как в РФ, но в той же Украине большинство ит-шников, которые "работают" на фирму, на самом деле являются ФОПами (ИП). Огромное количество номадов работают с заказчиками напрямую. Я бы сказал, что из всех своих знакомых, я не знаю ни одного, кто бы зарабатывал более-менее приличные деньги, находясь в трудовых отношениях с компанией.
Да, я в курсе, что в Украине все на ФОПах (хотя вроде в свое время Diia City же собирались запускать по аналогии с белорусским ПВТ). Также как в Грузии многие на похожем режиме. Но в РБ и РФ скажем не так, большинство все же на трудовых, и по NHR это дает возможность именно платить 0% в Португалии. Причем для многих это именно вынужденная мера, чтобы не платить налоги 2 раза (то есть может и были бы не против платить в Португалии, но непонятно как при этом не платить в РБ / РФ, если работодатель не хочет переводить трудовой в сервисный контракт, да еще с оплатой в "недружественную" страну).
таки да. это то, с чего я и начинал. про "льготные" 32%. заплатили 1500, получил меньше 1000.
Ну суммарные 32% (с соцстрахом) по трудовым договорам для любой суммы по западным меркам это очень даже побожески.
А 0% по NHR это не про офшор, а скорее про двойное налогооблажение.
Да, доход должен быть трудовым. Подоходный сейчас для нерезидентов РФ и резидентов РФ одинаковый - 13% (хотя сейчас прогрессивный ввели, но это отдельная история и там тоже не такая большая разница). На соцстрах для ИТ компаний тоже льгота ЕМНИП 7.3% или около того (в РБ скажем 35% но со средней, что еще меньше).
То есть по факту в сумме будет около 20%, хотя в самой ПТ (не считая первых 2 лет льгот) будет около 32% по NHR (хотя если сумма меньше 4к в месяц, есть неработающая жена, то можно и почти 20% без NHR получить с вычетами). Но последнее это если работать по ИП, на что не каждый работодатель согласится - переводить трудовой договор в договор услуг, так как в большинстве стран это считается уходом от налогов.
Причем тут налог на прибыль не понял. Равно как и зачем открывать фирму, если ты в ней работаешь. То что нельзя быть ИП в России или Грузии на упрощенке (под 6%) и исключать потом по NHR этот доход в Португалии никто вроде никогда и не заявлял (так как это было бы странно)
В общем 0% это далеко не замануха, но и конечно надо понимать, когда его можно получить, а когда нет. Точнее нужно понимать, что 0% это если ты платишь налоги, но в другой стране (то есть для тебя налоговая нагрузка не изменится и именно в этом была задумка NHR, а не сделать оффшор).
Не, это без соцстраха. С соцстрахом 20 получается где-то при доходе 3.5к. Но тут можно с калькуляторами поиграться их много в телеграм чатах соответствующих.
так-то налоговая "одобряет" практически любые декларации. потому как реальную документальную проверку они при этом не делают.
Ну они по словам всех бухгалтеров уже 10 лет как одобряют такие декларации, и за все время существования NHR никаких проблем не было.
Первый - доход должен быть именно от трудового договора (рос ИП, укр ФОП, груз аналог - не подходят). И второй - сама работа должна выполняться не на территории страны (что для айтишников легко проверяется - по штампу в паспорте :))
Что значит должна выполняться? Кому должна? Вы я так понимаю аппелируете к пункту 18.1.а, про "dependente decorrentes de atividades nele exercidas", что очень любят делать в налоговых чатах? Это все обсуждение конечно веселое, но когда речь доходит до подачи декларации, оказывается что в Anexo A (куда нужно вносить трудовые доходы на территории Португалии), первым же пунктом идет NIF работодателя. После чего даже апологеты, того что такие доходы нужно считать местными, говорят ну что делать - заполняйте в Anexo J (иностранные), а значит и в Anexo L (NHR) на исключение. То есть сама налоговая не дает ввести иностранные трудовые доходы как местные.
Ну и те, до кого руки у налоговой в итоге не дойдут по чистому везению.
Ага, у всех бухгалтеров, с которыми я общался, десятки клиентов (некоторые уже под десять лет) подают доходы на исключения по NHR, но всем "чисто везет". При этом физически нет никакого способа их подавать по другому.
Что значит не даёт 0%? Налоговая отлично одобряет декларации, с трудовым доходом(то есть наемный класса А) в L секции (NHR) если подоходный уплачен в стране заказчика. И сегурансу вы разве что добровольно платить сможете, так как ее в принципе юрики платят, то есть ИП или компания (физики соответственно на практике практически никто не платят).
Ну и до 48 процентов это в определенной степени страшилка. С неработающей женой и какими никакими вычетами больше 20 процентов получается при доходе больше тысяч так 5 в месяц (при средней по стране 1,5к или типа того). Что меньше той же Испании.
Не понял, а чем мешают отчёты на мастере в версионном режиме. Работают и работают. У нас есть некоторые проекты с объемом и количеством данных больше чем у вас (там терабайтами измеряется объем данных, а логика десятками тысяч событий ) и работают без проблем. Да, что-то отдельно в BI (OLAP) крутится, но и в OLTP более чем много по ряду причин.
Просто не надо блокировочники (пессимистичные блокировки в смысле) использовать в OLTP (что ручные на уровне сервера приложений, что автоматические на уровне СУБД) и будет счастье. А так, мы героически решаем проблемы, которые сами себе создаём.
С другой стороны, мы знали проблемные отчёты — обычно за большой период. С прошлой системы у людей осталась привычка выгружать вообще все «сырые» данные за период в XLS, а уже затем делать формулами всякие преобразования. Идея, что можно получить агрегат уже из SQL, была для них незнакомой и местами пугающей. В общем, по всей базе они собирали джойн, которым так известен интерфейс 1С, и оставляли его считаться, чтобы получить свои данные. Иногда сборка такого отчёта занимала часы, на которые и блокировались все другие пользователи: они страдали, а работа системы кратно замедлялась. Мы выявляли людей с такими отчётами, били по рукам. Люди плакали, говорили: «Нет, нам нужны данные от момента рождения Вселенной до её тепловой смерти». Просто ограничивали выборку, перенастраивали отчёт.
Но вообще то что 1С не использует версионные СУБД и их принцип работы (с update conflict'ами в частности), а предлагает блокировать все разработчику самому руками - это конечно треш. Что мешало им сделать нормально - загадка.
А если еще учесть, что они даже в типовых по вашим словам блокируют криво (что в общем предсказуемо, с учетом того, что это должен делать разработчик) и нужно все "переблокировать" внедренцы, то вообще слов нет. Только разве сочувствие, что кто-то умудрился выбрать такое решение.
Не совсем понял раздел конфликт блокировок. Мне казалось, что 1С уже очень давно для отчётов использует версионный режим READ_COMMITED_SNAPSHOT или как-то так он называется. Тогда отчёты не должны вешать транзакции. Потому как если они вешают, то это мрак, и будет вечный забег по граблям.
Ну как сказать, временные таблицы это своего рода локальные переменные. А вы предлагаете их заменить на использование других функций. Мало того что это не производительно, так это ещё тупо неудобно.
Ну при хоть сколько сложной транзакции на запись без временных таблиц очень сложно обойтись.
Впрочем масштабирование транзакций записи (то есть master-master) вообще штука такая себе, по двум причинам. а) Теорему САР никто не отменял. б) Тяжело представить систему, во всяком случае со сложными транзакциями (аля ERP), где с современными серверами можно уткнуться в проблему вертикального масштабирования на мастере (предполагая что там только транзакции записи будут, остальные на слейвах). Естественно предполагая что запросы эффективны (то есть все подперто индексами и т.п.).
ЗЫ: А хотя туплю, речь в данном случае же про шардинг, а не зеркалирование. Тут если честно не помню, как теорема САР работает.
Автор по ссылке все же лукавит. PostgreSQL не поддерживает JPPD для агрегированных подзапросов. Но если агрегацию вынести из подзапроса, то JPPD поддерживается:
Не понятно какое отношение это имеет к predicate push down. Тут же просто инлайнится запрос, так как вы по сути его руками переписали (и это можно сделать только в очень ограниченных случаях, скажем, что будет если у вас будет два подзапроса, если LEFT JOIN идет с подзапросом и т.п.)
Это разные СУБД. Для примера, с одной стороны у PostgreSQL есть DISTINCT ON и нужно избавляться от лишних CTE с ROW_NUMBER() OVER (,,,), а с другой стороны, агрегированные подзапросы нужно конвертировать в LATERAL.
Так о том и речь. Что 1С просто транслятор в синтаксис СУБД, поэтому переезд между СУБД, это не просто мигрировал данные из одной в другую. Это может быть переписывание огромного числа запросов. Кстати LATERAL ЕМНИП он вообще не поддерживает.
Поэтому кстати часто бывает, что когда продают некоторые решения на 1С говорят, хотите PostgreSQL - конечно поставим. А потом на практике оказывается, что они под PostgreSQL нифига не работают.
Соответственно, если вы изначально писали запросы под MS SQL, переехав на PostgreSQL, у вас даже самые простые запросы могут начать сваливаться в пробег по всей базе, со всеми вытекающими.
И это только Predicate Push Down. У Postgres'а еще очень много веселых косяков с неправильной статистикой в подзапросах, с cross-column статистикой. У MS SQL все с этим куда получше. Конечно с этим можно было бы бороться, делая "материализацию подзапросов" на лету (как это делает тот же lsFusion), но 1С так тоже не умеет.
В общем это все конечно хорошо, но такой переезд если у вас чуть более сложное приложение чем CRUD, может потребовать переписывания огромного числа запросов (если конечно удастся их найти, с учетом того что в этого время база будет лежать, а пользователи ныть).
Если руками делать predicate push down'ы как это делается в типовых:
ВЫБРАТЬ
РасходнаяНакладнаяСостав.Номенклатура,
УчетНоменклатурыОстатки.КоличествоОстаток
ИЗ
Документ.РасходнаяНакладная.Состав КАК РасходнаяНакладнаяСостав
ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.УчетНоменклатуры.Остатки(,
Номенклатура В (
ВЫБРАТЬ Номенклатура
ИЗ Документ.РасходнаяНакладная.Состав
ГДЕ Ссылка = &Документ)) КАК УчетНоменклатурыОстатки
ПО УчетНоменклатурыОстатки.Номенклатура = РасходнаяНакладнаяСостав.Номенклатура
ГДЕ
РасходнаяНакладнаяСостав.Ссылка = &Документ И
(УчетНоменклатурыОстатки.КоличествоОстаток < РасходнаяНакладнаяСостав.Количество ИЛИ
УчетНоменклатурыОстатки.КоличествоОстаток ЕСТЬ NULL)
и другие оптимизации, то да PostgreSQL будет работать. Просто отзывы в данном случае - средняя температура по больнице. То есть если разработчики (или "доработчики") не будут делать такие оптимизации, то под MS SQL все будет работать хорошо, а под PostgreSQL ляжет. И наоборот, если делать, то PostgreSQL будет даже лучше работать (так как в плане оптимизации сложных запросов он, скажем прямо, туповат, зато время планирования и выполнения у него отличное, как у автомата калашникова условно).
Это я понимаю. Просто ирония, что скажем в типовых работа с документами часто специально делается через времянки, именно чтобы избежать N+1 и бомбардировки сервера одиночными запросами. А при этом существенная часть механизмов все еще завязана на объектную технику.
То есть у вас как будто разработчики типовых борются с разработчиками платформы :) Последние топят за ORM и не хотят уходить от него уходить, а первые, я так понимаю для производительности, наоборот пытаются уйти максимально все делая запросами.
У PostgreSQL как минимум: нет predicate push down, очень ограниченная работа с cross-column статистикой и "утечки" памяти при активном использовании временных таблиц / сложных запросов (возможно это не утечки, а просто очень большой memory footprint, но сути дела это не меняет). Все это требует достаточно много оптимизаторов со стороны платформы (тем самым выполняя работу СУБД), чтобы сложное решение на нормальных объемах нормально работало на PostgreSQL.
Хотя конечно если у вас решение или очень простое или в нем мало данных (то есть грубо говоря < 100k активно используемых записей в таблице) или сделано императивно спагетти-кодом то может и на PostgreSQL взлететь. Но "стабильность в поддержке" тут не при чем.
Ну VIEW это все же не совсем то. Хотя может использоваться формально как workaround, но проблема что подход работы через VIEW не "модульный" (грубо говоря ты наследуешь классы не в месте объявления конкретного класса, а в месте объявления абстрактного класса ).
Ну у вас с платформой то разработчики работают, а не пользователи. Они если надо в for'е себе в ногу выстрелят (даже с большей легкостью). И со слабым контролем непонятно, так как как раз именно при групповом изменении обычно все идет одной транзакцией и она скорее всего тупо не успеет закончится (до того как ее снимут), так как обычно нужно много логики пересчитать / проверить, да и блокировок будет много (ну или update conflict'ов в версионном режиме).
Документ целиком как раз поменять/удалить можно.
Ну вот это как раз и странно. В тех же типовых со строками документа работа идет через времянки, то есть запросами (для производительности), а с другими объектами такой возможности нет (хотя справочник штука абстрактная, и может быть очень большим, больше чем строк в документах).
Ну сейчас после закрытия манифестао может и вывезут. Но не раньше чем через год :) Хотя для номадов в среднем все же не все так мрачно всегда было. Особенно с учетом того, что условия очень лайтовые. По сути выписка из банка, рабочий договор, договор аренды и справка о несудимости из основных документов.
Да, я в курсе, что в Украине все на ФОПах (хотя вроде в свое время Diia City же собирались запускать по аналогии с белорусским ПВТ). Также как в Грузии многие на похожем режиме. Но в РБ и РФ скажем не так, большинство все же на трудовых, и по NHR это дает возможность именно платить 0% в Португалии. Причем для многих это именно вынужденная мера, чтобы не платить налоги 2 раза (то есть может и были бы не против платить в Португалии, но непонятно как при этом не платить в РБ / РФ, если работодатель не хочет переводить трудовой в сервисный контракт, да еще с оплатой в "недружественную" страну).
Ну суммарные 32% (с соцстрахом) по трудовым договорам для любой суммы по западным меркам это очень даже побожески.
А 0% по NHR это не про офшор, а скорее про двойное налогооблажение.
Да, доход должен быть трудовым. Подоходный сейчас для нерезидентов РФ и резидентов РФ одинаковый - 13% (хотя сейчас прогрессивный ввели, но это отдельная история и там тоже не такая большая разница). На соцстрах для ИТ компаний тоже льгота ЕМНИП 7.3% или около того (в РБ скажем 35% но со средней, что еще меньше).
То есть по факту в сумме будет около 20%, хотя в самой ПТ (не считая первых 2 лет льгот) будет около 32% по NHR (хотя если сумма меньше 4к в месяц, есть неработающая жена, то можно и почти 20% без NHR получить с вычетами). Но последнее это если работать по ИП, на что не каждый работодатель согласится - переводить трудовой договор в договор услуг, так как в большинстве стран это считается уходом от налогов.
Причем тут налог на прибыль не понял. Равно как и зачем открывать фирму, если ты в ней работаешь. То что нельзя быть ИП в России или Грузии на упрощенке (под 6%) и исключать потом по NHR этот доход в Португалии никто вроде никогда и не заявлял (так как это было бы странно)
В общем 0% это далеко не замануха, но и конечно надо понимать, когда его можно получить, а когда нет. Точнее нужно понимать, что 0% это если ты платишь налоги, но в другой стране (то есть для тебя налоговая нагрузка не изменится и именно в этом была задумка NHR, а не сделать оффшор).
Не, это без соцстраха. С соцстрахом 20 получается где-то при доходе 3.5к. Но тут можно с калькуляторами поиграться их много в телеграм чатах соответствующих.
Ну они по словам всех бухгалтеров уже 10 лет как одобряют такие декларации, и за все время существования NHR никаких проблем не было.
Что значит должна выполняться? Кому должна? Вы я так понимаю аппелируете к пункту 18.1.а, про "dependente decorrentes de atividades nele exercidas", что очень любят делать в налоговых чатах? Это все обсуждение конечно веселое, но когда речь доходит до подачи декларации, оказывается что в Anexo A (куда нужно вносить трудовые доходы на территории Португалии), первым же пунктом идет NIF работодателя. После чего даже апологеты, того что такие доходы нужно считать местными, говорят ну что делать - заполняйте в Anexo J (иностранные), а значит и в Anexo L (NHR) на исключение. То есть сама налоговая не дает ввести иностранные трудовые доходы как местные.
Ага, у всех бухгалтеров, с которыми я общался, десятки клиентов (некоторые уже под десять лет) подают доходы на исключения по NHR, но всем "чисто везет". При этом физически нет никакого способа их подавать по другому.
Что значит не даёт 0%? Налоговая отлично одобряет декларации, с трудовым доходом(то есть наемный класса А) в L секции (NHR) если подоходный уплачен в стране заказчика. И сегурансу вы разве что добровольно платить сможете, так как ее в принципе юрики платят, то есть ИП или компания (физики соответственно на практике практически никто не платят).
Ну и до 48 процентов это в определенной степени страшилка. С неработающей женой и какими никакими вычетами больше 20 процентов получается при доходе больше тысяч так 5 в месяц (при средней по стране 1,5к или типа того). Что меньше той же Испании.
Не понял, а чем мешают отчёты на мастере в версионном режиме. Работают и работают. У нас есть некоторые проекты с объемом и количеством данных больше чем у вас (там терабайтами измеряется объем данных, а логика десятками тысяч событий ) и работают без проблем. Да, что-то отдельно в BI (OLAP) крутится, но и в OLTP более чем много по ряду причин.
Просто не надо блокировочники (пессимистичные блокировки в смысле) использовать в OLTP (что ручные на уровне сервера приложений, что автоматические на уровне СУБД) и будет счастье. А так, мы героически решаем проблемы, которые сами себе создаём.
А что тогда означает этот абзац?
С другой стороны, мы знали проблемные отчёты — обычно за большой период. С прошлой системы у людей осталась привычка выгружать вообще все «сырые» данные за период в XLS, а уже затем делать формулами всякие преобразования. Идея, что можно получить агрегат уже из SQL, была для них незнакомой и местами пугающей. В общем, по всей базе они собирали джойн, которым так известен интерфейс 1С, и оставляли его считаться, чтобы получить свои данные. Иногда сборка такого отчёта занимала часы, на которые и блокировались все другие пользователи: они страдали, а работа системы кратно замедлялась. Мы выявляли людей с такими отчётами, били по рукам. Люди плакали, говорили: «Нет, нам нужны данные от момента рождения Вселенной до её тепловой смерти». Просто ограничивали выборку, перенастраивали отчёт.Но вообще то что 1С не использует версионные СУБД и их принцип работы (с update conflict'ами в частности), а предлагает блокировать все разработчику самому руками - это конечно треш. Что мешало им сделать нормально - загадка.
А если еще учесть, что они даже в типовых по вашим словам блокируют криво (что в общем предсказуемо, с учетом того, что это должен делать разработчик) и нужно все "переблокировать" внедренцы, то вообще слов нет. Только разве сочувствие, что кто-то умудрился выбрать такое решение.
Не совсем понял раздел конфликт блокировок. Мне казалось, что 1С уже очень давно для отчётов использует версионный режим READ_COMMITED_SNAPSHOT или как-то так он называется. Тогда отчёты не должны вешать транзакции. Потому как если они вешают, то это мрак, и будет вечный забег по граблям.
Ну как сказать, временные таблицы это своего рода локальные переменные. А вы предлагаете их заменить на использование других функций. Мало того что это не производительно, так это ещё тупо неудобно.
Ну при хоть сколько сложной транзакции на запись без временных таблиц очень сложно обойтись.
Впрочем масштабирование транзакций записи (то есть master-master) вообще штука такая себе, по двум причинам. а) Теорему САР никто не отменял. б) Тяжело представить систему, во всяком случае со сложными транзакциями (аля ERP), где с современными серверами можно уткнуться в проблему вертикального масштабирования на мастере (предполагая что там только транзакции записи будут, остальные на слейвах). Естественно предполагая что запросы эффективны (то есть все подперто индексами и т.п.).
ЗЫ: А хотя туплю, речь в данном случае же про шардинг, а не зеркалирование. Тут если честно не помню, как теорема САР работает.
Не понятно какое отношение это имеет к predicate push down. Тут же просто инлайнится запрос, так как вы по сути его руками переписали (и это можно сделать только в очень ограниченных случаях, скажем, что будет если у вас будет два подзапроса, если LEFT JOIN идет с подзапросом и т.п.)
Так о том и речь. Что 1С просто транслятор в синтаксис СУБД, поэтому переезд между СУБД, это не просто мигрировал данные из одной в другую. Это может быть переписывание огромного числа запросов. Кстати LATERAL ЕМНИП он вообще не поддерживает.
Поэтому кстати часто бывает, что когда продают некоторые решения на 1С говорят, хотите PostgreSQL - конечно поставим. А потом на практике оказывается, что они под PostgreSQL нифига не работают.
Самая веселая часть такого перехода, что в PostgreSQL очень тупой оптимизатор. Например он не поддерживает Predicate Push Down:
https://habr.com/ru/companies/lsfusion/articles/463095/#jppd
А MS SQL поддерживает (пусть и не до конца).
При этом тот же 1С (в отличии скажем от lsFusion) Predicate Push Down тоже не поддерживает:
https://habr.com/ru/companies/lsfusion/articles/468415/#opt
Соответственно, если вы изначально писали запросы под MS SQL, переехав на PostgreSQL, у вас даже самые простые запросы могут начать сваливаться в пробег по всей базе, со всеми вытекающими.
И это только Predicate Push Down. У Postgres'а еще очень много веселых косяков с неправильной статистикой в подзапросах, с cross-column статистикой. У MS SQL все с этим куда получше. Конечно с этим можно было бы бороться, делая "материализацию подзапросов" на лету (как это делает тот же lsFusion), но 1С так тоже не умеет.
В общем это все конечно хорошо, но такой переезд если у вас чуть более сложное приложение чем CRUD, может потребовать переписывания огромного числа запросов (если конечно удастся их найти, с учетом того что в этого время база будет лежать, а пользователи ныть).
Если руками делать predicate push down'ы как это делается в типовых:
и другие оптимизации, то да PostgreSQL будет работать. Просто отзывы в данном случае - средняя температура по больнице. То есть если разработчики (или "доработчики") не будут делать такие оптимизации, то под MS SQL все будет работать хорошо, а под PostgreSQL ляжет. И наоборот, если делать, то PostgreSQL будет даже лучше работать (так как в плане оптимизации сложных запросов он, скажем прямо, туповат, зато время планирования и выполнения у него отличное, как у автомата калашникова условно).
Это я понимаю. Просто ирония, что скажем в типовых работа с документами часто специально делается через времянки, именно чтобы избежать N+1 и бомбардировки сервера одиночными запросами. А при этом существенная часть механизмов все еще завязана на объектную технику.
То есть у вас как будто разработчики типовых борются с разработчиками платформы :) Последние топят за ORM и не хотят уходить от него уходить, а первые, я так понимаю для производительности, наоборот пытаются уйти максимально все делая запросами.
У PostgreSQL как минимум: нет predicate push down, очень ограниченная работа с cross-column статистикой и "утечки" памяти при активном использовании временных таблиц / сложных запросов (возможно это не утечки, а просто очень большой memory footprint, но сути дела это не меняет). Все это требует достаточно много оптимизаторов со стороны платформы (тем самым выполняя работу СУБД), чтобы сложное решение на нормальных объемах нормально работало на PostgreSQL.
Хотя конечно если у вас решение или очень простое или в нем мало данных (то есть грубо говоря < 100k активно используемых записей в таблице) или сделано императивно спагетти-кодом то может и на PostgreSQL взлететь. Но "стабильность в поддержке" тут не при чем.
Вот тут немного подробней описано: https://habr.com/ru/companies/lsfusion/articles/463095
Ну VIEW это все же не совсем то. Хотя может использоваться формально как workaround, но проблема что подход работы через VIEW не "модульный" (грубо говоря ты наследуешь классы не в месте объявления конкретного класса, а в месте объявления абстрактного класса ).
Так в этом и вопрос, как платформа определеяет, если я условно напишу:
a = "SELECT a, b,"
a += "c FROM g" ;
Первый это полный запрос или нет. То есть нужно ли там синтаксическую / семантическую ошибку светить?
Именно. Хотел отредактировать комментарий и добавить это пояснение, но уже нельзя было его редактировать.
Ну у вас с платформой то разработчики работают, а не пользователи. Они если надо в for'е себе в ногу выстрелят (даже с большей легкостью). И со слабым контролем непонятно, так как как раз именно при групповом изменении обычно все идет одной транзакцией и она скорее всего тупо не успеет закончится (до того как ее снимут), так как обычно нужно много логики пересчитать / проверить, да и блокировок будет много (ну или update conflict'ов в версионном режиме).
Ну вот это как раз и странно. В тех же типовых со строками документа работа идет через времянки, то есть запросами (для производительности), а с другими объектами такой возможности нет (хотя справочник штука абстрактная, и может быть очень большим, больше чем строк в документах).