actualizaciones gran base de datos de volumen con un ORM

Question

me gusta herramientas ORM, pero a menudo he pensado que para los grandes cambios (miles de filas), parece ineficaz para cargar, actualizar y guardar cuando algo como

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

haría dar un rendimiento mucho mejor.

Sin embargo, suponiendo que uno deseara seguir esta ruta por motivos de rendimiento, ¿cómo se aseguraría de que los objetos almacenados en memoria caché se actualizaran correctamente?

Supongamos que está utilizando LINQ to SQL, y que ha estado trabajando en un DataContext, ¿cómo se asegura de que su ACTUALIZACIÓN de alto rendimiento se refleje en el gráfico de objetos de DataContext?

Esto podría ser un "no" o "utilizar activadores en la base de datos para llamar al código .NET que elimina la memoria caché", etc. etc., pero estoy interesado en encontrar soluciones comunes para este tipo de problema.

Answer 1

Tiene razón, en este caso, utilizar un ORM para cargar, cambiar y luego conservar registros no es eficiente. Mi proceso es algo como esto

1) el uso implementación temprana ORM, en mi caso NHibernate, exclusivamente

2) Dado que el desarrollo madura identificar problemas de rendimiento, que incluirá grandes cambios

3) Refactor ésos hacia fuera a SQL o SP enfoque

4) uso de comandos de actualización (objeto) para actualizar los objetos almacenados en caché,

Mi gran problema ha sido informar a otros clientes que la actualización se ha producido. En la mayoría de los casos, hemos aceptado que algunos clientes quedarán obsoletos, que es el caso con el uso de ORM estándar de todos modos, y luego verificar una marca de tiempo en la actualización/inserción.

Answer 2

Los ORM son ideales para un rápido desarrollo, pero tiene usted razón: no son eficientes. Son geniales porque no necesita pensar en los mecanismos subyacentes que convierten sus objetos en memoria en filas en tablas y viceversa. Sin embargo, muchas veces el ORM no elige el proceso más eficiente para hacerlo. Si realmente le importa el rendimiento de su aplicación, es mejor trabajar con un DBA para ayudarlo a diseñar la base de datos y ajustar sus consultas de manera adecuada. (o al menos comprende los conceptos básicos de SQL usted mismo)

Answer 3

ORMs simplemente no será tan eficiente como SQL hecho a mano. Período. Al igual que el ensamblador artesanal será más rápido que C#. Si la diferencia de rendimiento importa o no depende de muchas cosas. En algunos casos, el nivel más alto de abstracción que ofrecen los ORM puede valer más que un rendimiento potentamente más alto, en otros casos no.

Las relaciones de desplazamiento con el código de objeto pueden ser bastante buenas, pero como usted correctamente señala, existen problemas potenciales.

Dicho esto, personalmente veo que ORms es en gran parte una economía falsa. No me repetiré aquí, solo apunto a Using an ORM or plain SQL?

Answer 4

La mayoría de los ORM también tienen instalaciones para realizar actualizaciones grandes o "a granel" de manera eficiente. La sesión sin estado es uno de esos mecanismos disponibles en Hibernate para Java, que aparentemente estará disponible en NHibernate 2.x:

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

Answer 5

actualizaciones masivas son un diseño cuestionable. A veces parece necesario; en muchos casos, sin embargo, un mejor diseño de la aplicación puede eliminar la necesidad de actualizaciones masivas.

A menudo, alguna otra parte de la aplicación ya ha tocado cada objeto de a uno por vez; la actualización "masiva" debería haberse realizado en la otra parte de la aplicación.

En otros casos, la actualización es un preludio para el procesamiento en otro lugar. En este caso, la actualización debe ser parte del procesamiento posterior.

Mi estrategia de diseño general es refactorizar las aplicaciones para eliminar las actualizaciones masivas.