ORM vs consulta de base de datos tradicional, ¿cuáles son sus campos?

Question

ORM parece ser un modelo de rápido crecimiento, con ventajas y desventajas en su bando. Desde ASP.NET ultrarápido de Richard Kiessig (http://www.amazon.com/Ultra-Fast-ASP-NET-Build-Ultra-Scalable-Server/dp/1430223839/ref=pd_bxgy_b_text_b):

"Me encantan porque me permiten desarrollar sitios pequeños y de prueba de concepto de manera extremadamente rápida. Puedo dar un paso al costado de gran parte del SQL y la complejidad relacionada. que de otro modo necesitaría y me centraría en los objetos, la lógica empresarial y la presentación. Sin embargo, al mismo tiempo, tampoco me importan porque, desafortunadamente, su rendimiento y escalabilidad suelen ser muy pobres, incluso cuando están integrados con un sistema de almacenamiento en caché completa (la razón por la que se hace evidente cuando se da cuenta de que cuando se configura correctamente, SQL Server en sí es realmente un gran caché de datos"

Mis preguntas son:

• ¿Cuál es su comentario sobre la idea de Richard. ¿Estás de acuerdo con él o no? Si no, por favor diga por qué.

• ¿Cuál es el mejor campo adecuado para ORM y consulta de base de datos tradicional? en otras palabras, en las que debe utilizar ORM y donde se debe usar :) consulta a la base tradicional, que tipo/tamaño ... de las aplicaciones que debe elegir, sin duda, ORM consulta a la base/tradicional

Gracias de antemano

Answer 1

No puedo aceptar la queja común sobre los ORM que funcionan mal. He visto muchas aplicaciones SQL simples hasta ahora. Si bien es teóricamente posible escribir SQL optimizado, en realidad, arruinan todas las ganancias de rendimiento al escribir lógica comercial no optimizada.

Al usar SQL simple, la lógica de negocio se acopla mucho con el modelo db y las operaciones de la base de datos y las optimizaciones dependen de la lógica comercial. Como no hay ningún modelo, no puede pasar por estructuras de objeto completas. He visto muchas aplicaciones que pasan por las claves principales y recuperan los datos de la base de datos en cada capa una y otra vez. He visto aplicaciones que acceden a la base de datos en bucles. Y así. El problema es que, debido a que la lógica comercial ya es difícil de mantener, no hay espacio para más optimizaciones. A menudo, cuando intenta reutilizar al menos parte de su código, acepta que no está optimizado para cada caso. El rendimiento se pone malo por diseño.

Normalmente, un ORM no requiere que la lógica comercial se preocupe demasiado por el acceso a los datos. Algunas optimizaciones se implementan en el ORM. Hay cachés y la capacidad de lotes. Estas optimizaciones automáticas (y dinámicas en tiempo de ejecución) no son perfectas, pero desacoplan la lógica comercial de la misma. Por ejemplo, si un dato se usa condicionalmente, lo carga usando carga diferida a pedido (exactamente una vez). No necesita hacer nada para que esto suceda.

Por otro lado, los ORM tienen una curva de aprendizaje pronunciada. No utilizaría un ORM para aplicaciones triviales, a menos que el ORM ya esté en uso por el mismo equipo.

Otra desventaja del ORM es (en realidad no del ORM en sí mismo sino del hecho de que usted trabajará con una base de datos relacional y un modelo de objeto), que el equipo necesita ser fuerte en ambos mundos, el relacional como así como el oo.

Conclusión:

• ORM son de gran alcance para el negocio de lógica aplicaciones centradas con las estructuras de datos que son lo suficientemente que el tener un modelo OO voluntad ventajoso complejo.
• Los ORM generalmente tienen una curva de aprendizaje (de alguna manera) empinada. Para aplicaciones pequeñas, podría ser demasiado costoso.
• Las aplicaciones basadas en estructuras de datos simples, que no tienen mucha lógica para gestionarlo, probablemente sean más fáciles y simples de escribir en sql simple.
• Los equipos con un alto nivel de conocimiento de bases de datos y poca experiencia en tecnologías de oo serán probablemente más eficientes utilizando sql simple. (Por supuesto, dependiendo de las aplicaciones que escriban, podría ser recomendable que el equipo cambie el foco)
• Los equipos con un alto nivel de conocimiento y solo una base de datos básica son probablemente más eficientes utilizando un ORM.(Igual aquí, dependiendo de las aplicaciones que escriben que podría ser recomendable para el equipo para cambiar el foco)

Answer 2

ORM es bastante antiguo, al menos en el mundo de Java. Problemas principales con ORM: : modelo orientado a objetos y modelo relacional son bastante diferentes. - SQL es un lenguaje de alto nivel para acceder a los datos, pero cualquier lenguaje orientado a objetos como C#, Java o Visual Basic.Net Para obtener más información buscar en la web en cosas como 'relacional-objeto impedancia desajuste'

cualquier caso, una una buena estructura de ORM le ahorra bastante código de placa de caldera. Pero aún necesita tener conocimientos de SQL, cómo configurar un buen modelo de base de datos SQL. Comience creando un buen modelo de base de datos usando SQL, luego base su modelo OO en eso (no al revés)

Sin embargo, lo anterior solo se aplica si realmente necesita usar una base de datos SQL. Recomiendo investigar el movimiento NoSQL también. Hay cosas como Cassandra, Couch-db. Mientras busqué soluciones .net encontré esta pregunta stackoverflow: What NoSQL solutions are out there for .NET?

Answer 3

La programación se trata de escribir software para uso comercial. Mientras más nos concentremos en la lógica y presentación del negocio y menos con los tecnicismos que solo importan en ciertos momentos (cuando el software falla, cuando el software necesita actualización, etc.), mejor.

Recientemente leí sobre las conversaciones de escalabilidad de uno de los fundadores de Reddit, desde here, y una línea de lo que me llamó la atención fue la siguiente:

"tener que lidiar con las complejidades de bases de datos relacionales (relaciones , se une, restricciones) es una cosa del pasado ".

Por lo que he visto, el mantenimiento de un esquema de base de datos compleja, cuando se trata de escalabilidad, se convierte en un gran dolor como el sitio crece (se agrega un campo, reasigna limitaciones, re-mapa claves externas ... etc.) No estaba completamente claro para mí por qué es eso. Sin embargo, no están usando una base de datos NOSQL, están en Postgres.

Agregue a eso, aquí viene ORM, otra capa de abstracción. Simplifica la escritura de código, pero casi siempre con una penalización de rendimiento. Para mí, una simple biblioteca de abstracción de bases de datos servirá, al igual que las libs ligeras de RA junto con las consultas de "texto plano" específicas de la base de datos. No puedo mostrar ningún punto de referencia, pero con los ORM que he visto, la mayoría de ellos dice que "ORM a menudo puede ser lento".

Richard cubre ambos lados de la moneda, así que estoy de acuerdo con él.

En cuanto a los campos, realmente no entiendo el contexto de los "campos" sobre los que pregunta.

Answer 4

Estoy de acuerdo con la mayoría de los puntos ya hechos aquí.

Los ORM no son nuevos en .NET, LLBLGen ha existido por mucho tiempo, los he usado por más de 5 años en .NET.

He visto un código de ejecución muy malo escrito sin ORM (consultas SQL eficientes, índices incorrectos, llamadas de bases de datos anidadas - ¡ay!) Y código incorrecto escrito con ORMs - Estoy seguro de que he contribuido a algunos de el código malo también :)

Lo que yo añadiría es que un ORM es generalmente una herramienta poderosa y que mejora la productividad que le permite dejar de preocuparse por el código db de plomería para la mayoría de su aplicación y concentrarse en la aplicación misma. Cuando comienza a tratar de escribir un código complejo (por ejemplo, páginas de informes o UI complejas), necesita comprender lo que sucede debajo del capó: la ignorancia puede ser muy costosa. Pero, si se usan correctamente, son inmensamente potentes y la OMI no tendrá un efecto perjudicial en el rendimiento de las aplicaciones. Por mi parte, no estaría contento con un proyecto que no usó un ORM.

Answer 5

Como han dicho otros, puede escribir bajo código ORM y también puede escribir SQL de bajo rendimiento.

El uso de ORM no lo excusa de conocer su SQL y entender cómo encaja una consulta. Si puede optimizar una consulta SQL, generalmente puede optimizar una consulta ORM. Por ejemplo, los criterios de Hibernate y las consultas HQL le permiten controlar qué asociaciones se unen para mejorar el rendimiento y evitar declaraciones de selección adicionales. Saber cómo crear un índice para mejorar su consulta más común puede hacer o interrumpir el rendimiento de su aplicación.

Lo que ORM le compra es un acceso de base de datos uniforme y mantenible. Brindan una capa adicional de verificación para garantizar que su código OO coincida lo más posible con su acceso a la base de datos y evitar que cometa ciertas clases de errores estúpidos, como escribir código vulnerable a la inyección SQL. Por supuesto, puede parametrizar sus propias consultas, pero ORM le compra esa ventaja sin tener que pensar en ello.

Answer 6

Creo que este sitio utiliza Linq-to-SQL, y es "bastante" alto tráfico ... Creo que el tiempo que ahorra al escribir el código de placa de caldera para acceder/insertar/actualizar elementos simples es invaluable, pero siempre existe la opción de acceder a llamar a un SPROC si tiene algo más complejo, donde sabe que puede escribir directamente SQL acelerado.

No creo que estas cosas tengan que ser mutuamente excluyentes: use las ventajas de ambas, y si hay secciones de su aplicación que comienzan a desacelerarse, entonces puede optimizarlas según sea necesario.

Answer 7

Nunca recibí nada más que el dolor y la frustración de los paquetes de ORM. Si escribiera mi SQL de la manera en que lo autogenan, sí, afirmaría que soy rápido, mientras que mi código sería lento :-) ¿Alguna vez ha visto SQL generado por un ORM? Apenas tiene PK-s, usa FK-s solo para la interpretación errónea de "herencia" y si quiere hacer paginación, tira todo el conjunto de registros y luego descarta el 90% de él :-))) Luego bloquea todo a la vista ya que tiene que llevar una carga de registros como si volviera al procesamiento por lotes de IBM de 50 años.

Por un tiempo pensé que el mayor problema con ORM era astillarse (no tener un estándar en 50 años - cada API diferente, perdonar "modelo" :-) e ideologizar (todos vendiéndole una gran filosofía - siempre mejor que los demás, por supuesto :-) Luego me di cuenta de que era realmente el amateurismo total la causa del desastre y que todo lo demás es solo la consecuencia.

Entonces todo comenzó a tener sentido. ORM nunca fue diseñado para ser eficiente o fiable, ni siquiera estaba en la lista :-) Era un juguete académico, "conceptual" desde el primer día, el premio de consolación para los profesores cabreados que todos sus trabajos de investigación "relacionales" en Prolog se fue al desagüe cuando IBM y Oracle comenzaron a vender ese terrible asunto de SQL y ganaron :-)

Lo más cerca que llegué a confiar en uno fue LINQ, pero solo porque es posible y bastante fácil rechazar todo "seguimiento" y el uso es solo como capa de deserialización para el código SQL normal. Luego, leí cómo el objeto que gestiona la conexión puede desarrollar fallas espontáneas que sonaron como un GC prematuro mientras todavía tenía algunas cosas colgando. No hay manera de que iba a arriesgar mi cuello con él después de eso - pues no, no mi cabeza :-)

lo tanto, vamos a hacer una lista:

• totalmente descuidado código - no va a sufrir errores y potencia del pobre
  • No va a tomar los puntos muertos de 10-100 veces "transacciones" más largos de ORM
• drástica reducción de las capacidades - SQL tiene gran fuerza expresiva en estos días
• que Atar en flecos y API descuidado (todos los ORM tiene como objetivo secuestrar su código base)
  • consultas SQL son muy portátiles y conocimientos de SQL es totalmente portátil
• todavía tiene que saber SQL sólo para limpiar el desorden de todos modos ORM
• Por "prueba de concepto" sólo puedo serializar a los archivos binarios o XML
  no
  • mucho más lento, bibliotecas cero errores y uno de XPath puede seleccionar mejor de todos modos
  • De hecho, he hecho los sitios web de tráfico pesado de todos los archivos XML
  • si realmente se necesita gráfica real, entonces no tengo ningún uso para el DB - nada real para consultar
  • que puede serializar una burbuja y volcado en SQL como en 3 líneas de código
• Si alguien afirma que lo hace todo desde la interfaz de usuario a DB - Mantenga su código base bloqueados :-)
  • y copia de seguridad de su base de datos de nómina - me lo agradecerás este último :-)))
• bases de datos NoSQL son más honestos que ORM - "que se especializan en la persistencia"
  • y tienen una mejor calidad de código - no sorprende en absoluto

que sería la lista corta :-) BTW En la actualidad, los motores de SQL modernos hacen árboles e indexación espacial, sin mencionar paginación sin un solo registro perdido. Los ORM-s en realidad están "resolviendo" problemas de hace 10 años y promoviendo el amateurismo. En esa medida, NoSQL, también conocido como documento

Answer 8

ORM es mucho más antiguo que Java y .NET.El primero que conocía era TopLink para Smalltalk. Es una idea tan antigua como los objetos persistentes.

Cada marco de "CRUD en la web" como Ruby on Rails, Grails, Django, etc. utiliza ORM para la persistencia porque todos suponen que está comenzando con un modelo de objeto de hoja limpio: ningún esquema heredado con el que preocuparse. Comienzas con los objetos para modelar tu problema y generar la persistencia a partir de él.

A menudo funciona de la otra manera con los sistemas heredados: el esquema es de larga duración y es posible que tenga o no objetos.

Es sorprendente la rapidez con la que se puede poner en marcha un prototipo con frameworks "CRUD en la web", pero no creo que se utilicen para desarrollar aplicaciones empresariales en grandes corporaciones. Tal vez sea un prejuicio de Fortune 500.

Los administradores de bases de datos que conozco me dicen que no les gusta el SQL que generan los ORM porque a menudo es ineficiente. Todos desean una forma de afinarla a mano.

Answer 9

Soy el autor del libro con el texto citado en la pregunta.

Déjenme enfáticamente agregar que soy no argumentando en contra del uso de objetos comerciales o programación orientada a objetos.

Un problema que tengo con el ORM convencional, por ejemplo, LINQ to SQL o Entity Framework, es que a menudo conduce a que los desarrolladores realicen llamadas al DB cuando ni siquiera se dan cuenta de que lo están haciendo. Esto, a su vez, es un asesino de rendimiento y escalabilidad.

Reviso muchos sitios web por problemas de rendimiento, y he encontrado que DB chattiness es una de las causas más comunes de problemas graves. Desafortunadamente, ORM tiende a alentar el chattiness, en espadas.

Las otras quejas que tengo sobre ORM incluyen:

• No hay soporte para la dosificación de comandos
• No hay soporte para varios conjuntos de resultados
• No hay soporte para los parámetros con valores de tabla
• No hay soporte para asíncrono nativo llamadas (hacerlas desde un hilo de fondo no cuenta)
• Compatibilidad con SqlDependency y SqlCacheDependency es klunky si/cuando funciona en absoluto

No tengo objeción al uso táctico de ORM para abordar problemas comerciales específicos. Pero me opongo a usarlo al azar, hasta el punto de que los desarrolladores hagan cosas como hacer que la misma base de datos llame por docenas de tiempo en la misma página, o hacer consultas muy costosas sin tener en cuenta el almacenamiento en caché y las notificaciones de cambio, o descuidar totalmente las operaciones asincrónicas cuando se escala es una preocupación