Shocker.ProСкажем, нужно сделать обновление поля у кучи записей в таблице.

Пытаясь что-то найти по теме, наткнулся на расширение EntityFramework.Extended
http://habrahabr.ru/post/203214/
https://github.com/loresoft/EntityFramework.Extended


Кто как вообще поступает в подобных случаях?

В штатной ситуации пакетные обновления не требуются. А если вдруг потребовались, то это огромный косяк в бизнес-логике и в архитектуре данных. Если подобное когда-либо случается, засучиваем рукава и рефакторим.

Это расширение работает в обход контекста, т.е. по сути тоже самое, что втыкать SQL. Другого не дано.

Shocker.Pro,

Если данных обновлять надо не очень много, то можно отключить отслеживание изменений контекста. А если очень-очень много, то SQL + UPDATE, но повторюсь, это может просто сломать всё.

Monochromatique}{ вост просто не работал с большими объемами данных, вот ему и кажется, что без прямых инъекций можно обойтись.

Давай-ка реши мне следующие задачи при изменении, «прямыми инъекциями»:

1. Валидация изменений для каждого объекта.
2. Проверка допустимости изменения для пользователя по каждому объекту.
3. Дополнительные задачи инфраструктуры, такие как установка времени изменения, логгирование, и особенно, если ПО предполагает возможность отката последнего изменения.
4. Дополнительные бизнес-процессы, связанные с изменениями.

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

Если требуется часто делать пакетные изменения, возможно данные плохо нормализованы.

Shocker.Pro1) В прайс-листе в одной категории лежит 200 позиций, администратор подумал, что это слишком много, создал еще одну категорию, выбрал галочками по умозрительным критериям 100 позиций и перенес их в другую категорию.

2) Типовая функция для [около]почтовых программ: "пометить все|выделенные письма как [не]прочитанные"

3) Чистка устаревших записей лога

Кроме логов, которые совершенно точно надо чистить с помощью операции DELETE, остальные действия можно делать обычно, без «низкоуровневых» bulk операций.

МСУТы укурен? И причем тут "бизнес логика"?

Шта?

skyANAhVostt, хм. Пользователь удаляет аккаунт и надо всё с ним связанное деактивировать.

Не частое явление конечно, но вполне себе бизнес-логика :)

Об этом и речь.

Shocker.ProХорошо, как бы концептуально подошел к решению следующей задачи (сюжет основан на реальных событиях):

Есть прайс-лист организации - полмиллиона позиций (ну это полный, вместе с тем, чего уже нет в наличии).
Есть прайс-листы поставщиков, совокупно несколько миллионов позиций.

Прайсы поставщиков нужно периодически обновлять и формировать на основе их прайсов свой прайс. Каждый прайс поставщика - несколько [десятков] тысяч позиций. Его нужно втянуть, сравнить с уже имеющимся в базе, составить карту изменений (что появилось, что пропало, что вообще новое, никогда не было), актуализировать. После чего обновить собственный прайс (сотня тысяч позиций в наличии) - пересчитать наличие и цены с учетом новых реалий.

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

Shocker.ProhVosttТакую задачу я бы решал естественно запросами к БД, а не через EF контекст, если (скорее всего) с записями в прайс-листах не связаны никакие бизнес-процессы, они не представляют собой объекты домена приложения, т.е. это просто табличные данные, значит с ними вполне уместно работать запросами.как раз мой первоначальный вопрос был примерно об этой ситуации.

Ну технически, запросами. Уж как конкретно, прямыми SQL, или вызовом хранимки, или с помощью некоего экстеншена, это уже by design. Объёмы табличных данных большие, операция периодическая, значит это будет делать некий сервис.

skyANA Выбор ORM-стратегии (.NET)

В Абрикосе в импорте данных используется Dapper.

Даппер кажется и рожден для того, чтобы колбасить данные, импорт/экспорт/массовая обработка... :)

skyANAМой посыл в том, что если грамотно изолировать слой доступа к данным, то где надо внутри импользуешь EF, где надо Dapper, а где-то и голый ADO.NET.

Согласен, тоже хотел об этом сказать.

МСУЧем тебе не "штатная ситуация" для обновления сотрудников из 1С / аксапты / сапа? Обновляет отдельная песочница в виде вин сервиса.

Это всё в рамках транзакции? Если нет, то оч. плохо.

МСУhVosttЭто всё в рамках транзакции?
Зачем? Откуда такие требования?

P.S. Если произошел сбой, следующая синхронизация добъёт отвалившийся кусок. Плюс, на реальных массивах данных транзакционность априори вредна и опасна. Это ж тебе не пару тыщ строк обновить. Но там уже более серьезные инструменты вступают в бой типа SSIS, BizTalk и иже с ними.

Ни разу не сталкивался с ситуацией, когда транзакционность опасна и вредна. Первый раз вообще такое слышу.

И к твоему изначальному вопросу, ProcessEmployee(db, u, employees); — что это, если не бизнес-логика? Только не говори, что это просто строка кода, или «какой-та метад».

Shocker.ProhVosttНи разу не сталкивался с ситуацией, когда транзакционность опасна и вредна.при интенсивной многопользовательской работе в разы увеличивает вероятность дедлоков. На TSQL всегда старался избежать транзакции там, где сбой не является критичным

Не вижу причин решать эту проблему средствами БД.

МСУВот тебе тот же элементарный кейс, синхронизация информации (фион, табельный номер, подразделение) о сотрудниках из аксапты. 30К сотрудников, представь себе ситуацию, когда ночной джоб перелопатил 29.9К сотрудников и по каким-то причинам упал. Какой смысл отката всей транзакции? Да и зачем мне захватывать объекты в БД с определенным уровнем изоляции? Что за бред?

Ты видать совсем плохой стал, на старость лет. Тебя надо отстранить от разработки ПО и отправить срочняком на пенсию, маразм сыграл с тобой плохую шутку, такую ахинею нести. А чо, нормально. Подумаешь, кому-то из 30К сотрудников не повезёт, и будет бедняга к админам бегать, чтоб его инфу актуализировали.

Писец. Тупее в жизни ничего не слышал.

МСУНу какая-то минимальная бизнес-логика, не спорю. Но не в этом суть, суть описана выше. Процессинг данных на EF - реальная задача.

Какая ещё суть? От гениальности твоего «изобретения» я аж прослезился. Может замутишь по этой теме докторскую?

МСУМда, hVostt опять вляпался в то, в чём не разбирается... :) Интересно, как на этот раз собирается выкручиваться.
Больше всего радуют такие мемберы, которые в теме ноль, но сцуко совет расчехлить - гавно вопрос

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

Алексей КЯ сталкивался. Стараюсь делать транзакции как можно меньше. От греха подальше, нуегонах...

Поделись плз кейсами, когда она вредна?

МСУА ты предлагаешь всем 30К сотрудникам к админу бегать, чтобы их актуализировали? Тебя уволят

Угу, тебя с такими подходами ещё в банковской системе не хватало. Ну подумаешь, часть бабла прошло, часть не прошло. Пох...

Дурик, у тебя унылый, пахабный и тупой пример. Придумай что-нибудь ещё.

И поясни вот этот говновысер, плз. Желательно хоть как-то аргументировать, а не жалкие пуки в воду:

МСУна реальных массивах данных транзакционность априори вредна и опасна

П.С. даже на собеседовании джуниора тебе за такое ушлёпство рассмеются в лицо и отправят мести улицы. умник хренов.

МСУЛишний раз неофита попинать просто задорно :)

С такой пиналкой тебе только голубей дрессировать.

МСУТы просто еще не дорос до этого высера. Клепай лучше формочки и тестируй код :)

Ты напоминаешь героя одной из книжек Носова:

-- Моей музыки не понимают, -- говорил он. -- Еще не доросли до моей музыки. Вот когда дорастут -- сами попросят, да поздно будет. Не стану больше играть.

Вместо пояснений, унылые пуки в лужу. Я в прочем этого от тебя и ожидал. Мой вопрос на счёт пояснения твоих громких заявлений можно считать риторическим, так как ты просто тупо слил.

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

Пока что вижу, что это ты из космоса так и не вылазишь никогда. Я спросил у человека — он ответил.

Спросил же у тебя, ты максимум изображаешь из себя шута, хотя может и не изображаешь вовсе... Просто шут.

МСУP.S. Хвост, купи себе уже голову

Мне — зачем? Я же не туплю как ты. Расскажи-ка, как ты обходишься без транзакций людям.

МСУhVostt, что ты там бурлишь себе под нос, транзактщионщик? Иди паси коз, и не забудь их оттестировать

МСУ ты в своём репертуаре: пук-пук-пук в лужу. И сел в лужу. Ведь ты единственный в мире знаешь, как работать с БД без транзакций

Алексей КПро лишние блокировки, в том числе повышающие вероятность мёртвой блокировки, выше уже написали.

Наблюдал случай, один админ самовольно решил почистить таблицу с логами. Откуда ему было знать, что MSSQL выполняет команду delete from Log where EntryDate < @d в одной транзакции. Он сначала пару часов ждал, пока оно удалится. Потом ему надоело ждать, он отменил запрос. Потом все столько же ждали, пока отменится транзакция. На всё ушло часов ~6.

Из-за невозможности отключения транзакций например чистка БД от старых записей превращается в мучение, хотя казалось бы...

А как выкрутились из ситуации? Забили на чистку логов?

МСУА я разве без них обхожусь?

Ты только недавно говорил «АПРИОРИ ОПАСНА И ВРЕДНА», скажи, ты не осёл случайно? Упёртое тупое животное. Сам сказал «опасна и вредна» и тут же даёшь заднюю.

МСУ,

И ещё скажи мне, как вот это твоё высказывание:

МСУпредставь себе ситуацию, когда ночной джоб перелопатил 29.9К сотрудников и по каким-то причинам упал

Согласуется с твоими ссылками про проблемы в многопользовательской среде, ведь как бы «ночной джоб» работает обычно с БД в одно рыло, монопольно?

Я всё жду не дождусь от тебя реальный проблемный кейс.