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

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?

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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