使用 ORM 进行大容量数据库更新答案

【问题标题】：Large volume database updates with an ORM使用 ORM 进行大容量数据库更新
【发布时间】：2010-10-14 19:09:01
【问题描述】：

我喜欢 ORM 工具，但我经常认为对于大型更新（数千行），在类似的情况下加载、更新和保存似乎效率低下

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

会提供更好的性能。

但是，假设出于性能原因想要走这条路线，那么您将如何确保缓存在内存中的所有对象都得到正确更新。

假设您正在使用 LINQ to SQL，并且您一直在处理 DataContext，您如何确保您的高性能 UPDATE 反映在 DataContext 的对象图中？

这可能是“你没有”或“使用数据库上的触发器来调用删除缓存的 .NET 代码”等，但我很想听听这类问题的常见解决方案。

【问题讨论】：

这不是使用 ORM 的原因之一吗？即它提供了同步内存对象和更新的存储对象的机制？该机制当然是 ORM 特定的
是的，但我的观点是，如果您使用 ORM 工具，并希望使用直接 SQL 方法提高批量更新的性能，那么您将失去 ORM 的一些好处。

标签： sql database performance orm caching

【解决方案1】：

您是对的，在这种情况下，使用 ORM 加载、更改然后持久化记录效率不高。我的过程是这样的

1) 早期实现只使用 ORM，在我的例子中是 NHibernate

2) 随着开发的成熟，会发现性能问题，其中将包括大量更新

3) 将这些重构为 sql 或 SP 方法

4) 使用 Refresh(object) 命令更新缓存的对象，

我最大的问题是通知其他客户更新已经发生。在大多数情况下，我们已经接受了一些客户端将是陈旧的，无论如何标准 ORM 使用都是这种情况，然后检查更新/插入的时间戳。

【讨论】：

【解决方案2】：

大多数 ORM 还具有高效执行大型或“批量”更新的功能。无状态会话是 Hibernate for Java 中可用的一种此类机制，显然将在 NHibernate 2.x 中可用：

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

【讨论】：

【解决方案3】：

ORM 非常适合快速开发，但您是对的——它们效率不高。它们很棒，因为您无需考虑将内存中的对象转换为表中的行并再次返回的底层机制。然而，很多时候 ORM 并没有选择最有效的流程来做到这一点。如果您真的关心应用程序的性能，最好与 DBA 合作，帮助您设计数据库并适当调整查询。（或者至少自己了解SQL的基本概念）

【讨论】：

【解决方案4】：

批量更新是一个有问题的设计。有时它们似乎是必要的；然而，在许多情况下，更好的应用程序设计可以消除批量更新的需要。

通常，应用程序的某些其他部分已经一次触及每个对象； “批量”更新应该在应用程序的其他部分完成。

在其他情况下，更新是其他地方处理的前奏。在这种情况下，更新应该是稍后处理的一部分。

我的一般设计策略是重构应用程序以消除批量更新。

【讨论】：

@Candy Chiu：你是说你没看答案？还是答案中的具体例子不够清楚？你的评论是什么意思？仅仅因为别人说“构建批量更新”而构建批量更新并不能解决有问题的设计决策。
"用一些用户定义的值刷新数据库中的数据"。在这种情况下，如果触及多行，则可能存在规范化问题。多行可能应该被提取到不同的表中，以便单行更新正确完成工作。
@SLott：只有一个概念实体。
@Candy Chiu：首先：“一个概念实体”和“批量更新”不兼容。散装 == 很多。第二：规范化不会改变“概念”实体。
@SLott：一个概念实体通常意味着一个表定义。批量更新更新此实体（表）的实例（行）。在这种情况下不需要规范化。

【解决方案5】：

ORM 不会像手工编写的 SQL 那样高效。时期。就像手工汇编程序会比 C# 更快一样。这种性能差异是否重要取决于很多事情。在某些情况下，ORM 为您提供的更高级别的抽象可能比潜在的更高性能更有价值，而在其他情况下则不然。

使用目标代码遍历关系可能非常好，但正如您正确指出的那样，存在潜在问题。

话虽如此，我个人认为 ORms 在很大程度上是一种虚假的经济。我不会在这里重复自己，只是指向Using an ORM or plain SQL?

【讨论】：