hVosttДавай так, вот ты привёл пример на EF с группами объектов. Импорт таким способом сколько выполняется по времени? Примерно, ну хотя бы приблизительно?
Вот тут я приводил тебе типовой расчет 17314369 , я не понимаю, ты реально жопой читаешь текст?

hVosttИ второй вопрос, работает ли кто-то ещё с БД в то время, когда запускается этот джоб? Скажешь? Я тогда отвечу, почему такое решение плохое.
Конечно работает. Я выше писал про различные часовые пояса 17310432 , ты каким местом читаешь? Так же с этой БД могут работать другие джобы, ETL под data warehouse и так далее. Работа кипит всегда.

hVosttМСУ, А за подробно описанный процесс конечно спасибо, слегка неожиданно, вот можешь же!
Тебе этот процесс уже битый день люди втирают, так что не надо мне тут заслуги приписывать. Вина только в тебе

Вот тут 17310383 я выкладывал юнит тест реального джоба, который процессит сотрудников (это вин сервис, источником является odata сервис аксапты, приемником - отдельная БД под различное ПО). Как видишь отработка заняла 181 минуту, это примерно навскидку 0.4 секунды на одного сотрудника. Но это тестовая БД, к слову. На боевой БД сотрудников побольше, но и мощностя иные.

И еще, касательно оптимизации. Джобы выполняются асинхронно, разумеется. Если нужно оптимизировать процессинг, всегда можно его разнести на n джобов, что ускорит отработку. Либо как вариант процессить в n потоках. Как по мне, больше нравится второй вариант, он чище и грамотнее. Но подойдет и ленивый первый вариант, где нужно просто разделить выборки по какому-то искуственному критерию, как то даты, дни недели дат, чётность ID, группы, части top/skip и так далее. Оптимизация бесконечна :)

hVosttМСУЗачем рубить весь процессинг из-за одной пакетной ошибки? Так хоть 95% сотрудников распределишь.
Ну если такое у вас (или у вашего заказчика) является нормальным, тогда твоё решение ваще гуд!
Объясни мне, почему такое решение может быть ненормальным? Вот Сахават что-то булькал-булькал и слился, так и не смог объяснить, накойхер (с) ему всё или ничего.

hVosttНо у наших заказчиков требования к надёжности весьма высокие, а у нас требования к нашим разработкам очень высокие.
У так тоже требования к надежности высокие, где ты тут увидел какие-то послабления?

hVosttНедопустимы такие косяки, когда система в какой-то момент времени находится в неконсистентном состоянии.
У меня тоже самое, неконсистентное состояние исключено.

hVosttЕсли импорт, то либо загрузилось всё без ошибок, либо загрузка с косяками не нужна вообще, ни в каком виде, ни 80%, ни 99%. Надо разбираться в чём ошибка, исправлять и добиваться 100% успешной транзакции.
Ситуации разные бывают, есть такие предметные области, в которой нужно именно 100% импорта. Например, рассмотрим загрузку месячных продаж. Бизнесу не нужно 90% продаж за день 01.02.2015, поэтому если именно 01.02 оказался "битым" днем, такая информация не играет роли. Но зачем отказывать всесь импорт, если 02.02.2015 полностью 100% прогрузился? О том и речь, что с неконсистентное бывает иногда неконсистентным, такой вот каламбур.

hVosttЧто за дебильный типично колхозно-крестьянский принцип: запихнуть что хоть как-то пихается, а что не пихается запинать ногами, да и пох. Не знаю, если только ты там не для колхоза свои решения пилишь.
Выше я объяснил. Люди работают с продажами за 02.02.2012, которые 100% прогрузились. Зачем их лишать этой возможности?

hVosttViPRos181мин!!!!!!
ужас какой то

Да, вот это я понимаю, «РЕАЛЬНЫЙ МАССИВ ДАННЫХ»!
Даже не так. НЕ РЕАЛЬНЫЙ!
Всякое гугло сосёт причмокивая

3 часа - это долго? Ребята, шли бы вы кур пасти, серьёзно

Ситуации разные бывают, есть такие предметные области, в которых нужно именно 100% импорта. Например, рассмотрим загрузку месячных продаж. Бизнесу не нужно 90% продаж за день 01.02.2015, поэтому если именно 01.02 оказался "битым" днем, такая информация не играет роли. Но зачем откатывать весь импорт, если 02.02.2015 полностью 100% прогрузился? О том и речь, что неконсистентное бывает иногда консистентным, такой вот каламбур.