¿Usando un ORM o SQL simple? [cerrado]

Para algunas de las aplicaciones que desarrollé (luego olvidé), he estado escribiendo SQL simple, principalmente para MySQL. Aunque he usado ORM en python como SQLAlchemy , no me quedé con ellos por mucho tiempo. Por lo general, era la documentación o la complejidad (desde mi punto de vista) lo que me frenaba.

Lo veo así: use un ORM para la portabilidad, SQL simple si solo va a usar un tipo de base de datos. Realmente estoy buscando consejos sobre cuándo usar un ORM o SQL al desarrollar una aplicación que necesita soporte de base de datos.

Pensando en ello, sería mucho mejor usar un contenedor ligero para manejar las inconsistencias de la base de datos en lugar de usar un ORM.

Los ORM tienen algunas características agradables. Pueden manejar gran parte del trabajo de copiar columnas de bases de datos a campos de objetos. Generalmente manejan la conversión de los tipos de fecha y hora del idioma al tipo de base de datos apropiado. En general, manejan las relaciones de uno a muchos de manera muy elegante también al instanciar objetos anidados. Descubrí que si diseña su base de datos teniendo en cuenta las fortalezas y debilidades del ORM, se ahorra mucho trabajo al introducir y sacar datos de la base de datos. (Querrá saber cómo maneja el polimorfismo y las relaciones de muchos a muchos si necesita mapearlos. Son estos dos dominios los que proporcionan la mayor parte del 'desajuste de impedancia' que hace que algunos llamen a ORM la 'vietnam de la informática' .)

Para las aplicaciones que son transaccionales, es decir, usted realiza una solicitud, obtiene algunos objetos, los atraviesa para obtener algunos datos y los muestra en una página web, el impuesto sobre el rendimiento es pequeño y, en muchos casos, ORM puede ser más rápido porque almacenará en caché los objetos. visto antes, de lo contrario habría consultado la base de datos varias veces.

Para las aplicaciones que generan muchos informes o que manejan una gran cantidad de filas de bases de datos por solicitud, el impuesto ORM es mucho más pesado y el almacenamiento en caché que hacen se convierte en una gran carga inútil de acaparamiento de memoria. En ese caso, el mapeo SQL simple (LinQ o iBatis) o consultas SQL codificadas a mano en un DAL delgado es el camino a seguir.

He encontrado que para cualquier aplicación a gran escala te encontrarás usando ambos enfoques. (ORM para CRUD directo y SQL / thin DAL para informes).

Hablando como alguien que pasó bastante tiempo trabajando con JPA (Java Persistence API, básicamente la API ORM estandarizada para Java / J2EE / EJB), que incluye Hibernate, EclipseLink, Toplink, OpenJPA y otros, compartiré algunos de mis observaciones

1. Los ORM no son rápidos. Pueden ser adecuados y la mayoría de las veces es adecuado, pero en un entorno de alto volumen y baja latencia son un no-no;
2. En lenguajes de programación de propósito general como Java y C #, necesita mucha magia para que funcionen (por ejemplo, tejido de carga en Java, instrumentación, etc.);
3. Cuando utilice un ORM, en lugar de alejarse de SQL (que parece ser la intención), se sorprenderá de la cantidad de tiempo que pasa ajustando XML y / o anotaciones / atributos para que su ORM genere SQL con rendimiento;
4. Para consultas complejas, realmente no hay sustituto. Al igual que en JPA, hay algunas consultas que simplemente no son posibles que están en SQL sin procesar y cuando tienes que usar SQL sin procesar en JPA no es bonito (C # /. Net al menos tiene tipos dinámicos, var, que es mucho mejor que una matriz de objetos);
5. Hay muchas "trampas" cuando se usan ORM. Esto incluye un comportamiento involuntario o inesperado, el hecho de que tiene que construir la capacidad de realizar actualizaciones SQL en su base de datos (mediante el uso de refresh () en JPA o métodos similares porque JPA almacena en caché todo de manera predeterminada para que no capture una base de datos directa actualización: ejecutar actualizaciones directas de SQL es una actividad de soporte de producción común);
6. El desajuste relacional de objetos siempre va a causar problemas. Con cualquier problema de este tipo, existe una compensación entre la complejidad y la integridad de la abstracción. A veces sentí que JPA fue demasiado lejos y alcanzó una ley real de rendimientos decrecientes donde la complejidad no estaba justificada por la abstracción.

Hay otro problema que requiere un poco más de explicación.

El modelo tradicional para una aplicación web es tener una capa de persistencia y una capa de presentación (posiblemente con servicios u otras capas intermedias, pero estas son las dos importantes para esta discusión). Los ORM fuerzan una vista rígida desde su capa de persistencia hasta la capa de presentación (es decir, sus entidades).

Una de las críticas a los métodos SQL más crudos es que terminas con todos estos VO (objetos de valor) o DTO (objetos de transferencia de datos) que se usan simplemente con una consulta. Esto se promociona como una ventaja de los ORM porque se deshace de eso.

La cuestión es que esos problemas no desaparecen con los ORM, simplemente se mueven hacia la capa de presentación. En lugar de crear VO / DTO para consultas, crea objetos de presentación personalizados, generalmente uno para cada vista. ¿Cómo es esto mejor? En mi humilde opinión no lo es.

He escrito sobre esto en ORM o SQL: ¿ Ya llegamos? .

Mi tecnología de persistencia de elección (en Java) en estos días es ibatis. Es un envoltorio bastante delgado alrededor de SQL que hace más del 90% de lo que JPA puede hacer (incluso puede hacer una carga diferida de las relaciones, aunque no está bien documentado) pero con mucho menos sobrecarga (en términos de complejidad y código real).

Esto surgió el año pasado en una aplicación GWT que estaba escribiendo. Mucha traducción de EclipseLink a objetos de presentación en la implementación del servicio. Si estuviéramos usando ibatis hubiera sido mucho más sencillo crear los objetos apropiados con ibatis y luego pasarlos de arriba a abajo de la pila. Algunos puristas podrían argumentar que esto es Bad ™. Tal vez sea así (en teoría), pero te digo qué: habría llevado a un código más simple, una pila más simple y más productividad.

Digo SQL simple para R eads, ORM para CUD .

El rendimiento es algo que siempre me preocupa, especialmente en las aplicaciones web, pero también el mantenimiento y la legibilidad del código. Para abordar estos problemas, escribí SqlBuilder .

ORM no es solo portabilidad (que es un poco difícil de lograr incluso con ORM, para el caso). Lo que le proporciona es básicamente una capa de abstracción sobre un almacén persistente, cuando una herramienta ORM lo libera de escribir consultas SQL repetitivas (selecciona por PK o por predicados, inserciones, actualizaciones y eliminaciones) y le permite concentrarse en el dominio del problema.

Cualquier diseño respetable necesitará algo de abstracción para la base de datos, solo para manejar la falta de coincidencia de impedancia. Pero el primer paso más simple (y adecuado para la mayoría de los casos) que esperaría sería un DAL, no un ORM de peso pesado. Sus únicas opciones no son aquellas en los extremos del espectro.

EDITAR en respuesta a un comentario que me solicita que describa cómo distingo DAL de ORM:

Un DAL es lo que escribe usted mismo, tal vez a partir de una clase que simplemente encapsula una tabla y asigna sus campos a propiedades. Un ORM es código que no escribe o mecanismos de abstracción inferidos de otras propiedades de su esquema dbms, principalmente PK y FK. (Aquí es donde puede averiguar si las abstracciones automáticas comienzan a filtrarse o no. Prefiero informarlas intencionalmente, pero esa puede ser mi preferencia personal).

Cada herramienta tiene su propósito y visión. He creado http://www.jooq.org/ exactamente para satisfacer sus necesidades, aunque iBatis es probablemente una buena solución para usted también.

jOOQ tiene características básicas de ORM, pero se centra principalmente en las cosas que supongo que la mayoría de los desarrolladores necesitan más, cuando intentan encontrar el mejor ORM para sus necesidades:

• codigo de GENERACION
• unión variable (eso es un dolor en JDBC)
• Abstracción de sintaxis SQL (para evitar errores de sintaxis)

Pero a menudo van demasiado lejos y proporcionan tanta abstracción que no pensarías que se están ejecutando contra un RDBMS. Por otro lado, elegiste un RDBMS precisamente porque

• es una fuente de datos robusta
• SQL puede hacer muchas cosas buenas y eficaces (selecciones anidadas, uniones, combinaciones complejas, etc.). A menudo, los ORM no pueden hacer estas cosas.
• puede manejar transacciones y sesiones usted mismo
• tiene UDT y procedimientos almacenados

jOOQ aborda exactamente estos puntos. Funcionará tan bien como JDBC, pero sin el dolor.

El dilema de si usar un marco o no es bastante común en el escenario de desarrollo de software moderno.

Lo importante es comprender que cada marco o enfoque tiene sus pros y sus contras, por ejemplo, en nuestra experiencia, hemos encontrado que ORM es útil cuando se trata de transacciones, es decir, operaciones de inserción / actualización / eliminación, pero cuando se trata de obtener datos con complejos resultados se vuelve importante evaluar el rendimiento y la efectividad de la herramienta ORM.

También es importante comprender que no es obligatorio seleccionar un marco o un enfoque e implementar todo en eso. Lo que queremos decir con eso es que podemos tener una combinación de ORM y lenguaje de consulta nativo. Muchos marcos ORM dan puntos de extensión al complemento en SQL nativo. Deberíamos tratar de no usar demasiado un marco o un enfoque. Podemos combinar ciertos marcos o enfoques y llegar con una solución adecuada.

Puede usar ORM cuando se trata de inserción, actualización, eliminación, control de versiones con alto nivel de concurrencia y puede usar SQL nativo para la generación de informes y listas largas

La clave que hizo que mi uso de ORM realmente volara fue la generación de código. Estoy de acuerdo en que la ruta ORM no es la más rápida, en términos de rendimiento del código. Pero cuando tiene un equipo de mediano a grande, la base de datos está cambiando rápidamente, la capacidad de regenerar clases y asignaciones de la base de datos como parte del proceso de construcción es algo brillante para la vista, especialmente cuando usa CI. Por lo tanto, es posible que su código no sea el más rápido, pero su codificación lo será: sé cuál tomaría en la mayoría de los proyectos.

Mi recomendación es desarrollar usando un ORM mientras el Schema todavía es fluido, usar perfiles para encontrar cuellos de botella, luego ajustar las áreas que lo necesitan usando Sql sin procesar.

Otro pensamiento, el almacenamiento en caché integrado en Hibernate a menudo puede mejorar enormemente el rendimiento si se usa de la manera correcta. No más volver a la base de datos para leer los datos de referencia.

No existe una solución 'una herramienta para todos', y esto también es cierto para la pregunta '¿debería usar un / m o no? '.

Yo diría: si tiene que escribir una aplicación / herramienta que esté muy centrada en los 'datos', sin mucha otra lógica, entonces usaría SQL simple, ya que SQL es el lenguaje específico del dominio para este tipo de aplicaciones.

Por otro lado, si tuviera que escribir una aplicación comercial / empresarial que contenga mucha lógica de 'dominio', entonces escribiría un modelo de clase rico que podría expresar este dominio en código. En tal caso, un mapeador OR / M puede ser muy útil para hacerlo con éxito, ya que le quita mucho código de plomería.

Una de las aplicaciones que he desarrollado fue un bot IRC escrito en python. Los módulos que usa se ejecutan en subprocesos separados, pero no he descubierto una manera de manejar los subprocesos cuando uso sqlite. Sin embargo, eso podría ser mejor para una pregunta por separado.

Realmente debería haber reformulado tanto el título como la pregunta real. Nunca he usado un DAL antes, en ningún idioma.

Utilice un ORM que funciona como SQL, pero proporciona comprobaciones en tiempo de compilación y seguridad de tipos. Como mi favorito: Data Knowledge Objects (divulgación: lo escribí)

Por ejemplo:

for (Bug bug : Bug.ALL.limit(100)) {
  int id = bug.getId();
  String title = bug.getTitle();
  System.out.println(id +" "+ title);
}

Transmisión completa Fácil de configurar (no hay asignaciones para definir, lee sus esquemas existentes). Admite combinaciones, transacciones, consultas internas, agregación, etc. Prácticamente todo lo que puede hacer en SQL. Y ha sido probado desde conjuntos de datos gigantes (series de tiempo financieras) hasta triviales (Android).

Sé que esta pregunta es muy antigua, pero pensé que publicaría una respuesta en caso de que alguien la encontrara como yo. Los ORM han recorrido un largo camino. Algunos de ellos te ofrecen lo mejor de ambos mundos: hacer que el desarrollo sea más productivo y mantener el rendimiento.

Eche un vistazo a los datos SQL ( http://sqldata.codeplex.com ). Es un ORM muy ligero para c # que cubre todas las bases.

Para su información, soy el autor de los datos SQL.

Me gustaría agregar mi voz al coro de respuestas que dicen "¡Hay un término medio!".

Para un programador de aplicaciones, SQL es una mezcla de cosas que es posible que desee controlar y cosas que seguramente no desea que se moleste en controlar.

Lo que siempre he querido es una capa (llámela DAL, ORM o micro-ORM, no me importa cuál) que se encargará de las decisiones completamente predecibles (cómo deletrear palabras clave SQL, dónde van los paréntesis, cuándo inventar alias de columna, qué columnas crear para una clase que contiene dos flotantes y un int ...), mientras me deja a cargo de los aspectos de nivel superior de SQL, es decir, cómo organizar JOINs, cálculos del lado del servidor, DISTINCIONES, BY GRUPALES, subconsultas escalares, etc.

Entonces escribí algo que hace esto: http://quince-lib.com/

Es para C ++: no sé si ese es el lenguaje que está utilizando, pero de todos modos podría ser interesante ver esta versión de cómo podría ser un "término medio".