Большие объемы обновлений базы данных с помощью ORM

Question

Мне нравятся инструменты ORM, но я часто думал, что для больших обновлений (тысячи строк) кажется неэффективным загружать, обновлять и сохранять, когда что-то типа

UPDATE [table] set [column] = [value] WHERE [predicate]

даст гораздо лучшую производительность.

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

Допустим, вы используете LINQ to SQL и работали над DataContext. Как убедиться, что ваше высокопроизводительное UPDATE отражено в графе объектов DataContext?

Это может быть «не надо» или «использовать триггеры в БД для вызова кода .NET, который сбрасывает кэш» и т. Д., И т. Д., Но мне интересно услышать общие решения для такого рода проблем.

Answer 1

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

1) Ранняя реализация использует ORM, в моем случае NHibernate, исключительно

2) По мере развития разработки выявляют проблемы с производительностью, которые будут включать большие обновления

3) Рефакторинг подходов к SQL или SP

4) Используйте команду Обновить (объект) для обновления кэшированных объектов,

Моя большая проблема - информирование других клиентов о том, что произошло обновление. В большинстве случаев мы согласились с тем, что некоторые клиенты устарели, как в случае со стандартным использованием ORM, и затем проверили метку времени при обновлении / вставке.

Answer 2

Большинство ORM также имеют средства для эффективного выполнения больших или «массовых» обновлений. Сеанс без сохранения состояния - это один из таких механизмов, доступных в Hibernate для Java, который, очевидно, будет доступен в NHibernate 2.x:

http://ayende.com/Blog/archive/2007/11/13/What-is-going-on-with-NHibernate-2.0.aspx

Answer 3

ORM отлично подходят для быстрой разработки, но вы правы - они неэффективны. Они хороши тем, что вам не нужно думать о базовых механизмах, которые преобразуют ваши объекты в памяти в строки в таблицах и обратно. Однако во многих случаях ORM не выбирает наиболее эффективный процесс для этого. Если вы действительно заботитесь о производительности своего приложения, лучше всего работать с администратором баз данных, чтобы помочь вам спроектировать базу данных и соответствующим образом настроить ваши запросы. (или хотя бы сами понимаете основные понятия SQL)

Answer 4

Массовые обновления - сомнительный дизайн. Иногда они кажутся необходимыми; однако во многих случаях лучший дизайн приложения может устранить необходимость в массовых обновлениях.

Зачастую некоторые другие части приложения уже касались каждого объекта по одному; «массовое» обновление должно было быть сделано в другой части приложения.

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

Моя общая стратегия проектирования заключается в рефакторинге приложений для устранения массовых обновлений.

Answer 5

ORM просто не будут такими эффективными, как ручной SQL. Период. Точно так же, как созданный вручную ассемблер будет быстрее, чем C #. Важность разницы в производительности зависит от многих вещей. В некоторых случаях более высокий уровень абстракции ORM дает вам больше, чем потенциально более высокую производительность, в других случаях нет.

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

При этом я лично считаю ORms ложной экономикой. Я не буду повторяться здесь, но просто укажу на Использование ORM или простого SQL?