¿Cuáles son los beneficios de utilizar la abstracción de base de datos por ORM? [cerrado]

19

Estoy empezando a usar el ORM recomendado por el marco que elijo, y aunque me gusta la idea de la capa adicional de abstracción que proporciona el ORM, estoy empezando a darme cuenta de lo que esto realmente significa. Significa que ya no estoy trabajando con mi base de datos (mysql) y todas las características específicas de mysql han desaparecido, fuera de la ventana, como si no existieran.

La idea que tiene el ORM es que está tratando de ayudarme haciendo todo lo agnóstico de la base de datos. Esto suena genial, pero a menudo hay una razón por la que elijo un sistema de base de datos específico. Pero al seguir la ruta agnóstica de la base de datos, el ORM toma el mínimo común denominador, lo que significa que termino con el conjunto más pequeño de características (las admitidas por todas las bases de datos).

¿Qué sucede si sé que a largo plazo no cambiaré la base de datos subyacente? ¿Por qué no acceder también a las funciones específicas de la base de datos?

jblue
fuente
2
+1: muy interesante. En general, he defendido los ORM, pero generalmente he considerado que los RDBMS son iguales (que recientemente comencé a ver como incorrectos).
Steven Evers
Parece que solo quieres confirmar tu propia opinión; un blog puede ser mejor para ti que un sitio de preguntas y respuestas.
Probablemente no necesite más que lo que proporciona el ORM. Solo desea almacenar sus datos de objeto en una base de datos y eso es lo que hará el ORM. No debería necesitar ninguna otra 'característica'.
CJ7

Respuestas:

14

Lo veo de la misma manera. Cualquier abstracción que no le permita meterse debajo de ella cuando sea necesario es mala, porque conduce a todo tipo de inversiones de abstracción feas en su código.

En el trabajo, tenemos un ORM de cosecha propia que funciona bastante bien, pero para los momentos en que necesitamos algo que sus características no proporcionan explícitamente, hay un método que toma una cadena y la coloca directamente en la consulta que está generando, lo que permite para el uso de SQL sin procesar cuando sea necesario.

OMI, cualquier ORM que no tenga esta característica no vale los bits de los que está compilado.

Mason Wheeler
fuente
drops it directly into the query it's generatingSuena interesante. ¿Sabes cuánto tiempo te llevó escribir este ORM de cosecha propia? Me gustaría ver algo como esto en uno de los ORM de código abierto que hay.
jblue
+1. Trabajar con el aspecto más importante de mi aplicación (datos) es lo último que quiero abstraer y perder la conexión.
Fosco
1
Me gusta poder sumergirme cuando sea necesario, siempre y cuando ese buceo implique cruzar una valla metafórica: "Aquí hay dragones. Cuida tu paso".
Frank Shearar
1
@Jblue: No tengo idea. Todo fue escrito hace años, mucho antes de que me contrataran. Establecieron un ORM antes de que alguien usara el término. Por lo general, simplemente se llama "el Modelo de Objetos" en nuestra base de código.
Mason Wheeler
3
Estoy de acuerdo. Para las cosas básicas y habituales, los ORM son muy útiles. Pero a veces necesita profundizar un poco más, y si el ORM no le da esa habilidad, entonces es una fuente más de problemas para usted.
Nikos Steiakakis
14

el ORM toma el mínimo común denominador

Debo estar en desacuerdo con tu declaración. Tomaré nHibernate como ejemplo. Este marco admite muchas bases de datos, incluidas las más populares, independientemente de la versión (y las funciones compatibles), al igual que la mayoría de los ORM.

Nota rápida: solo menciona la abstracción de la base de datos. Ese es uno de los muchos beneficios, pero realmente creo que las características orientadas a objetos son más poderosas (por ejemplo, herencia). Y You design your domain model first...

... De vuelta a la abstracción. No es el mínimo común denominador. En nHibernate , tienes dialectos. Le permite usar un mismo código para consultar diferentes bases de datos. Los dialectos se encargan de la gestión de funciones por usted. La afirmación correcta es eso a given dialect will try to use all the power of a given database system.

Como ejemplo, tome el SqlServer2005dialecto que cuando se introdujo estaba aprovechando las nuevas características de paginación de SQL Server 2005. El uso de ese dialecto en lugar de SqlServer2000solo aumentó sus actuaciones.

Por supuesto, hay excepciones, pero no encontré una sola en muchos años de trabajo con nHibernate, y mis aplicaciones están muy centradas en los datos.


fuente
+1 por abogar por NHibernate. Un poco de una curva de aprendizaje en comparación con otros ORM, pero el esfuerzo bien vale la pena.
richeym
1
Me gustaría saber de algunos DBA sobre esto. En mi último trabajo, Hibernate no fue más que un problema (el SQL que generó fue absolutamente desagradable)
Fosco el
+1 para este comentario Es perfecto. Cuando comience a comparar el poder de un buen ORM como nHibernate (con almacenamiento en caché, carga diferida, etc.), verá por qué esta abstracción es buena y por qué sus necesidades específicas de la base de datos son menos importantes.
Chris Holmes
1
Fosco, dale otra oportunidad a nHibernate. Al igual que cualquier otra tecnología, debe comprender lo que está sucediendo dentro, para usarla correctamente.
+1, ORM es una intersección máxima de lo que Java puede hacer con lo que puede hacer un controlador JDBC en particular. Usted es libre de elegir la cantidad de inversiones que desea hacer en la capa de persistencia de su aplicación
bobah
5

La idea es clara, pero nunca me han movido al punto de usar una herramienta ORM. Simplemente no ha sido un problema para mí escribir el SQL yo mismo (o manejar cualquier almacenamiento que se use). Pero, tengo el lujo de trabajar en un número menor de proyectos con una vida útil más larga del producto, por lo que una vez que la manipulación de SQL y DB codificada a mano está en su lugar, está en su lugar. Además, obviamente puede manejar cualquier consulta SQL directa que necesite sin tener que adaptar su proceso a la forma de pensar de la herramienta ORM.

Entonces, supongo que las preguntas deberían ser antes de saltar a una:

¿ Realmente estás ganando algo al usarlos? Es decir, ¿está ahorrando una cantidad suficiente de esfuerzo al implementar una herramienta ORM para que valga la pena usarla y para que valga la pena agregar una complicación adicional a su sistema? (Esto es particularmente cierto para las aplicaciones comerciales, donde esa 'pieza' adicional ahora es un vector adicional para posibles problemas de soporte)

Y luego, ¿tendrá la capa de abstracción adicional un impacto negativo en la aplicación? ¿Va a ser más lento que el SQL codificado a mano, etc.

Gran maestro B
fuente
5

O / RM ha sido criticado regularmente. Ted Neward lo llamó el " Vietnam de la informática " hace unos años. O / RM

comienza bien, se vuelve más complicado a medida que pasa el tiempo, y en poco tiempo atrapa a sus usuarios en un compromiso que no tiene un punto de demarcación claro, ni condiciones de victoria claras, ni una estrategia de salida clara.

A menos que simplemente escriba su propio mapeo ad-hoc (que es una buena solución en muchos casos, como ya lo han dicho otros), podría buscar alternativas como usar una base de datos no relacional. Algunos dicen que una base de datos verdaderamente objetiva es mejor, otras palabras de moda mencionadas en este contexto son LINQ, Ruby y Tutorial D. Supongo que, en contraste con las bases de datos verdaderamente relacionales, existen bases de datos verdaderamente objetivas. Pero en la práctica descubrí que el modelado de datos conceptuales, es decir, para averiguar sobre qué objetos del mundo real desea almacenar datos y cómo se relacionan estos objetos, es más importante que descubrir cómo expresar su modelo conceptual en cualquier lenguaje de programación o base de datos.

Jakob
fuente
2
Gran lectura allí. He completado el círculo de la carrera y he vuelto a adoptar el modelo relacional con completo éxito.
Jé Queue
2
+1 @Xepoch - He tenido un reciente acerca de face re: ORMs - ¿por qué SQL se queda fuera? Abstracción, claro, pero ORM parece promover la fobia a SQL.
sunwukung
1
@sunwukung, no siempre estuve de acuerdo, pero ahora creo que SQL debería considerarse una capa lógica de primera clase, no solo algo que se usa como protocolo de cable.
Jé Queue
3

Cual es la alternativa?

Esta es una noción interesante. Al abstraer las características de la base de datos subyacente, definitivamente perdemos algunas de las características de la implementación de la base de datos específica. (Si deberíamos depender o no de características específicas de la base de datos es otro argumento) Supongo que esto podría resolverse mediante ORM específicos de la base de datos que le permitan acceder a las características específicas, pero eso podría ser más problema de lo que vale y un paso en el dirección incorrecta.

Al final del día, tienes que preguntarte: ¿cuál es la alternativa?

¿Deberíamos dejar de usar ORM y volver a escribir todo el acceso a la base de datos nosotros mismos? Claro que podríamos perder el acceso a algunas características de la base de datos a través del ORM, pero siempre puede acceder a las que usan técnicas de la vieja escuela. Al final, las ganancias que obtienes en productividad superan por completo las desventajas.

Jaco Pretorius
fuente
Me gustaría cuestionar la necesidad de utilizar una base de datos racional. Me molesta que las personas salten inmediatamente a RDBMS, incluso si no son la solución correcta. Las bases de datos de objetos, por ejemplo, proporcionan una solución muy elegante para muchos problemas. ¿Son perfectos? No, pero la gente rara vez se molesta en evaluarlos. Hay una tendencia inquietante de "Necesito almacenar datos, ¡usaré SQL!"
Matt Olenik
66
@Matt: los RDBMS son una tecnología muy probada y comprobada y bien entendida. Hay toneladas de personas con experiencia con ellos y un gran número de herramientas de terceros. Desde el punto de vista empresarial, hay mucho valor en eso cuando se trata de algo extremadamente valioso como sus datos. En proyectos más pequeños, todavía tiene valor poder iniciar un proyecto (como un servicio web LAMP) y tener la mayoría del software allí mismo y bien documentado.
David Thornley
3

Un ORM básicamente equivale a " Procedimientos no almacenados ". Ahí acuñé un término.

Todo lo que hace un ORM, puede replicarlo con vistas, disparadores y procedimientos almacenados. Ayudan a abstraer el SQL sin procesar y pueden mantener consistentes las bases de datos normalizadas. Pero solo funciona bien para casos simples. Si hay demasiados datos de máquina para procesar, pueden convertirse en una pérdida de rendimiento. (Los ORM en PHP a menudo toman el lado del script de datos, porque las cadenas del constructor de SQL no pueden abstraer todo).

Pero como de costumbre, todo depende de la aplicación y la tarea en cuestión.

mario
fuente
2
"Procedimientos no almacenados": el término apropiado es "SQL parametrizado". Solo está rascando la superficie de lo que un ORM maduro puede hacer por usted (procesamiento por lotes, carga
lenta,
@richeym: la mayoría de los ORM en PHP no usan declaraciones preparadas ni marcadores de posición parametrizados. Es el escape y la concatenación de SQL todo el camino. Seguro que brindan ventajas de mayor nivel sobre las tediosas consultas manuales de SQL. Sin embargo, desde el punto de vista lógico, eliminan la lógica de procesamiento de la base de datos, por lo tanto, "procedimientos no almacenados".
mario
3

Una cosa que duele al usar ORM es que muchos de sus fanáticos tienden a afirmar que ya no necesitamos conocer la teoría SQL y RDB. Los resultados varían desde divertidos hasta completamente catastróficos. Y esto a pesar de las millones de veces que los fabricantes y expertos de ORM afirman que debemos conocer bien la teoría de SQL y RDB para usar y configurar correctamente un ORM.

Por qué las personas toman una herramienta que tiene sus usos en muchos, pero no en todos los contextos, en una bala de plata mágica y universalmente aplicable, me supera.

luis.espinal
fuente
1

El año pasado trabajé en una aplicación interna que cambiaba con frecuencia, y estaba muy feliz de haber usado un ORM. La aplicación era una aplicación de apoyo para un equipo de gestión de cambios, y a medida que el proyecto más grande evolucionó, nuestra pequeña aplicación obtuvo nuevos requisitos para situaciones que no existían y que no se podían prever unos meses antes.

Gracias al ORM ( Propel , en PHP), dividimos parte de la lógica para el código, por lo que una función agregó la parte "es registro válido" de la consulta, otra parte de seguridad ("muestra estos registros solo si el usuario tiene estas capacidades "), ... Si la estructura subyacente cambió (un campo adicional que debe tenerse en cuenta para" validez de registro "), solo tuvimos que cambiar una función, no veinte cláusulas SQL.

Provenimos de una situación en la que todas (bueno, la mayoría) de las cláusulas SQL se almacenaban en un archivo XML separado, por lo que "los cambios en la base de datos serían fáciles de manejar". Créeme, no lo fueron. Una parte fue tan horrible que tuve que enviarla a The Daily WTF .

Si una consulta era demasiado complicada para expresarse con los criterios de Propel, o si necesitábamos algunas características específicas del proveedor (principalmente búsqueda de texto completo, ya que estábamos usando MySQL), esto no fue un problema con Propel. Puede agregar criterios personalizados , o cuando sea realmente necesario, usamos SQL sin formato ( ahora aún más fácil de combinar con objetos reales de Propel). Puede agregar fácilmente sus complementos específicos del proveedor a las clases generadas, de modo que tenga lo mejor de ambos mundos: sin SQL en el código de su aplicación, pero con todas las capacidades de su motor de base de datos.

Jan Fabry
fuente
1

Pero el punto es que puedes programar fuera de la base de datos, lo que significa que no necesitas pensar como si estuvieras en la base de datos.

Ahora trabajo en C # y uso LINQ mucho, así que muchísimos métodos fluidos. No necesito pensar en cómo se almacenan o encuentran mis objetos, o incluso cómo se guardan en el nivel del programa, y ​​muy poco en el nivel de la capa empresarial.

Muy a menudo, los métodos proporcionados por las Bases de datos específicas se usan en el DB Connector, por lo que obtiene esas optimizaciones sin necesidad de saber cuáles son.

Aún puede escribir funciones en el lado DB. A menudo puedes simplemente mapearlos.

Y, sobre todo, una separación como esa permite la capacidad de prueba y te obliga (un poco) a escribir un código mejor estructurado

mano quemada
fuente
2
Nuevamente, ¿por qué necesita programar fuera de la base de datos? ¿Por qué no hacer que la base de datos sea una parte integral de su desarrollo ya que ha elegido usar una en primer lugar? Si no necesita un RDBMS, ¿por qué colocar un ORM encima?
Jé Queue
1
Es una parte integral. Una base de datos funciona muy bien para mantener e imponer relaciones y recuperar datos sin procesar. Sin embargo, las cosas que desea hacer con estos datos probablemente ya se hayan manejado en el contenedor ORM. Y además de las cosas críticas, ¿por qué sacar la lógica de la capa empresarial?
burnt_hand
@burnt_hand - "Pero el punto es que puedes programar fuera de la base de datos, lo que significa que no necesitas pensar como si estuvieras en la base de datos". ¿Cuáles son las ventajas universales? Puedo verlo como una ventaja cuando su aplicación simplemente busca una forma de persistir objetos. Pero para los datos relacionales, OLTP y similares, la programación fuera de la base de datos es una forma de arruinarse a lo grande.
luis.espinal
@ luis.espinal: ¿qué significa fastidiarse mucho? Soy realmente curioso. ¿Tienes un ejemplo?
burnt_hand
@burnt_hand - en realidad tengo varios ejemplos reales. El más reciente implica un modelo de dominio muy grande y, como cuestión de rendimiento, el proyecto debe cargar todas las asignaciones de hibernación al inicio. La fábrica de sesiones resultante termina consumiendo hasta el 30% de la memoria utilizada ... solo para los enlaces. El código base está demasiado comprometido ahora con el ORM, y es imposible reescribirlo. Esto ahora tiene implicaciones reales ya que la aplicación se acerca a los límites físicos en el hardware que se suponía que debía ejecutar. Gorrón.
luis.espinal
1

Los ORM también pueden brindarle acceso a funciones específicas de la base de datos, depende de qué ORM esté utilizando y qué funciones brinde.

Por ejemplo, en el proyecto actual en el que estoy trabajando, estamos utilizando la API de persistencia de Java e Hibernate. Aun así, utilizamos varias características específicas de la base de datos, como la búsqueda en tablas con soundex.

Para mí, el principal beneficio de usar un ORM no es necesariamente que haga que una base de datos de aplicaciones sea independiente (aunque eso también es bueno), sino que, en su mayor parte, no tengo que pensar en cómo se almacenan las cosas y recuperado

Sin embargo , en algún momento lo más probable es que tenga que pensar en esto de todos modos, dependiendo de los requisitos para su aplicación. El ORM no es mágico.

Vetle
fuente
1

Escribí el mío, lo que me ayuda a hacer selecciones e inserciones más fácilmente.

Evey db cosa específica está disponible. Solo necesito escribir la consulta con la que la biblioteca me ayuda (puedo usar '?' Y params en lugar de nombrar manualmente un parámetro y usar .Add)

Supongo que la mía es una mierda mitad útil. Obtengo ayuda en el mundo ORM y hago partes importantes en el mundo de las consultas.


fuente
1

Escribir código para insertar y seleccionar, actualizar en línea o con procesos almacenados y mapearlos nuevamente a través del DAL es más la norma, más bien solo beneficioso en el caso excepcional. Los ORM disponibles, las bases de datos de soporte y los idiomas, la pregunta que debe hacerse, ¿por qué no está usando ORM?

Están estandarizados, son universales, especificados o genéricos. Además, es más rápido y más fácil de implementar. He usado subsónico, linq-to-sql y el marco de la entidad. Permite al desarrollador centrarse en la lógica y las reglas de negocio en lugar de la asignación de bases de datos.

Nickz
fuente
1
Hay muchas razones para usar o NO usar un ORM. Los ORM no son una panacea y muy pocas personas realmente saben cómo usarlos de manera efectiva. Además, en muchos casos, la lógica empresarial ya se refleja (en parte) de manera muy natural en las relaciones que ya existen en un RDBMS (este ha sido el escenario más común que he encontrado, pasado y presente). Un RDBM bien diseñado tiene una base matemática sólida, bien entendida, probada y verdadera. No todo debe modelarse con un RDMB, por supuesto, pero igualmente, un ORM tampoco es una solución universal.
luis.espinal
1

Mis (simples) dos centavos:

1: Hay ORMS y hay ORMS. Algunos ORMS se basan en Active Record, otros en Data Mapper, lo que en sí mismo es una consideración relevante, pero que requiere cierta investigación para comprender las implicaciones. En general, mi experiencia en PHP es que ORMS admite el primero, pocos admiten el último. Los ORM basados ​​en registros activos parecen tener uno de dos efectos: desnormalizan la base de datos o invocan una gran cantidad de clases para admitir las interacciones de objetos.

2: La ventaja de los ORM disminuye en correlación directa con la complejidad de la consulta que necesita ejecutar. Cuando tienes una relación simple y agradable, es decir, Usuarios -> Publicaciones, pueden funcionar muy bien. Esta (IMO) es la razón por la cual la mayoría de los ORM / frameworks usan ejemplos como este. Sin embargo, cuando necesita ejecutar consultas complejas, la cantidad de ORMQL que necesita generar es comparable a la longitud de la cadena de una consulta SQL normal, pero es menos eficiente debido al gráfico de objetos que ejecuta las invocaciones de consultas, lo que de alguna manera derrota el punto de abstracción. En resumen, los ORM son brillantes para el primer 30-50% de las tareas de su base de datos, pero terribles para el último. Creo que esta es otra razón por la cual la AR es tan frecuente.

3: ¿Por qué esconderse de la base de datos? ¿Usarías un lenguaje del lado del servidor para abstraer JavaScript?

Personalmente mezclo esos enfoques:

  • use ORM para lo básico, cargando "usuarios"
  • use un DAO que contenga varias consultas SQL precocidas (es decir, selectLike, selectWhere).
  • extienda el DAO donde sea necesario para agregar consultas personalizadas más específicas pero reutilizables
  • Proporcione acceso simple a la base de datos a través del DAO, es decir, $ data = Dao-> query (su cadena sql) para ejecutar consultas únicas.

Habiendo dicho todo eso, Doctrine 2 saldrá pronto, lo que parece realmente interesante.

sunwukung
fuente
0

Puede utilizar marcos de mapeador SQL como myBatis si desea utilizar las funciones sql.

Kolchanov
fuente
Esa no es realmente una respuesta a la pregunta de jblue sobre los beneficios de usar un mapeador de este tipo
Lukas Eder