hVosttРечь идёт именно о простоте или сложности. Сценарий топорного процессинга это всего лишь результат банальной лени разработчика, который не удосужился расчёхлить свои извилины и подумать.
По-моему, тут у кого-то другого проблемы с извилинами. Почему? Потому что он полный ноль в базах данных, репликациях, синхронизациях, фантомности данных, изоляциях, ETL, BI и так далее. Вот меня это и веселит, ты дуб дубом по теме, но несешь каку-то чушь про лень программиста.

hVosttНапример, вернёмся к твоему кейсу синхронизации 30К сотрудников. Учитывая, что синхронизация происходит периодически, наверняка среди 30К записей за короткий период реальных изменений реально меньше, чем 30К. Значит можно сначала определить весь объём этих изменений и выполнить их в рамках транзакции, это будет достаточно быстро, чтобы никто не испытывал проблем. Решение конечно же будет сложнее, чем тот кусок кода, что ты привёл, который ТУПО прогоняет один и тот же алгоритм обработки по всем записям.
Правильное замечание. Но это повлечет за собой доработку системы источника, что не всегда вписывается в сроки и приоритеты. 30К + 3 часа на процессинг - это не много, проще никого не напрягать и взять весь набор данных с источника. В любом случае, представь себе ситуацию, когда эти 30К - именно количество сотрудников, которых нужно отпроцессить. Либо пусть это будут продажи за месяц, количество экземпляров 100М. Включи абстракцию. Количество данных может быть и больше. Это не играет никакой роли. Главное одно - нужно отпроцессить много данных.

hVosttРефакторинг заключался в том, чтобы загрузить данные в служебные таблицы, никак не участвующие в бизнес-логике. Затем определить характер изменений. Затем в единой транзакции осуществить реальный импорт. Время импорта сократилось с 5-8 часов до 15 минут в среднем (в зависимости от объёма изменений). При чём ошибочные записи оставались в служебных таблицах и могли быть доимпортированы, после исправления ошибок в данных. Решение всех устроило и работает до сих пор по моим сведениям.
Это не рефакторинг, это оптимизация. Не путай теплое с мягким. Оптимизация нужна тогда, когда текущее положение дел становится неприемлемым. Это нормальный процесс. Изначально и заранее никто ничего не отпимизирует. На рельсы ставится готовое решение, которое удовлетворяет требованиям. Так что пример немного не в кассу.

hVosttТак что не лечи меня, милый товарищ на счёт невозможности и единственно правильного во всём мире решения этой задачи.
Включи голову уже. Твоя тупость безгранична.

hVosttТем более. Пол процессинга прошло, и тут произошло что-то из описанного тобой. В итоге в базе данных только половина актуализированной информации. Зипись чо.
Да, всё верно. А в твоём случае 0% актуальных данных. Это лучше?

hVosttПоэтому я тебе и говорил, что решение будет сложнее, чем представленное тобой, чтобы учитывать всё, нагрузку, требования, целостность, защищённость, возможность параллельного доступа, единую актуализацию... и не отключать свет, если пропала холодная вода.
О каких сложностях ты говоришь? Заблокировать в распределенной транзакции нахер всю таблицу сотрудников, чтобы все остальные соснули болт? Ты думаешь, что предлагаешь?

hVosttГарантии как раз таки обычно имеются. Как имеются и риски. Если тебе поставили задачу, а ты развёл руками «ну так нельзя...» и тычешь в нос чужими рекомендациям, то просто найдут другого исполнителя, способного пошевелить мозгами и решить задачу, а не ипать мозг.
Ну если есть риски, тогда какие вопросы? Предположим риск выстрелил. Твои действия?

hVosttМСУВ моём решении - единственно верный вариант. Других вариантов быть не может. Абсолютно.
В твоём решении возможно, всех деталей твоей задачи я не знаю, возможно именно такое решение там всех устраивает. Но это не единственно верный вариант. И другие варианты есть. Всегда есть.
Да какие детали. Суть одна - импорт нельзя заключать в транзакцию. Вообще. Никак. Нельзя. Напиши себе фломастером на лбу и запомни это.

hVosttТы напоминаешь мне дядю Билли, который орал 640Кб хватит всем!
Опять левый пример.