Cuándo usar un ORM (Sequel, Datamapper, AR, etc.) versus SQL puro para consultar

Question

Un colega mío está diseñando consultas SQL como la siguiente para producir informes, que se muestran en archivos de Excel a través de un externo consulta de datos. Actualmente, solo se requieren procesos de informes en el DB (sin operaciones CRUD).

Estoy tratando de convencerlo de que sería mejor usar un ORM ruby ​​para poder mostrar los datos en una aplicación de rieles/sinatra.

A pesar de las obvias ventajas de mostrar los datos, ¿qué ventajas tiene aprender cómo utilizar un ORM como Sequel o Datamapper?

Las consultas SQL que está escribiendo son claramente bastante complejas, y siendo relativamente nuevo en SQL, a menudo se queja de que es muy lento y confuso. ¿Es posible escribir consultas extremadamente complejas con un ORM? y si es así, ¿cuál es el más adecuado (he oído que Sequel es bueno para dbs heredados)? y ¿cuáles son las ventajas de aprender Ruby y usar un ORM versus seguir con SQL simple, al hacer consultas complejas de bases de datos?

Answer 1

Soy el mantenedor de DataMapper, y creo que para informes complejos debe usar SQL.

Aunque creo que algún día tendremos una DSL que proporcione la potencia y concisión de SQL, todo lo que he visto hasta ahora requiere que escriba más código de Ruby que SQL para consultas complejas. Prefiero mantener una consulta SQL de 5 líneas que 10-15 líneas de código Ruby para describir la misma operación compleja.

Tenga en cuenta que digo complejo ... si tiene algo simple, use los buscadores de compilación de ORM. Sin embargo, creo que hay una línea que puede cruzar donde SQL se vuelve más simple. Ahora, la mayoría de las aplicaciones no son solo informes. Puede tener muchas operaciones de tipo CRUD, para las cuales un ORM es perfectamente adecuado y mucho mejor que hacer esas cosas a mano.

Una cosa que un ORM generalmente proporcionará es algún tipo de organización para su lógica de aplicación. Puede agrupar el código en función de cada modelo en el mismo archivo. Por lo general es allí donde voy a poner la consulta SQL compleja, en lugar de incrustarlo en el controlador, por ejemplo:

class User 
    include DataMapper::Resource 

    property :id, Serial 
    property :name, String, :length => 1..100, :required => true 
    property :age, Integer, :min => 1, :max => 130 

    def self.some_complex_query 
    repository.adapter.select <<-SQL 
     SELECT ... 
     FROM ... 
     WHERE ... 
     ... more complex stuff here ... 
    SQL 
    end 
end 

Entonces puede simplemente generar el informe utilizando User.some_complex_query. También podría enviar la consulta SQL a una vista si desea seguir limpiando este código.

EDITAR: Por "ver" en la frase anterior quise decir vista RDBMS, en lugar de ver en el contexto MVC. Solo quería aclarar cualquier posible confusión.

Answer 2

ORM significa Mapeo Relacional de Objetos, pero mirando la consulta, su amigo parece querer una tabla de sumas y otros elementos muy específicos ... No he usado Ruby's Sequel, pero he usado Hibernate, y Python's SQLAlchemy (para Django/Turbogears) y aunque puedes hacer este tipo de consultas, no creo que esa sea su fortaleza.

El poder de ORM proviene de poder encontrar relaciones de objeto Foo-> Bar, digamos que desea que todos los objetos Bar para el campo de Foo sean mayores que X ... Ese tipo de cosas. Por lo tanto, no clasificaría un ORM como una solución "buena", aunque pasar a un lenguaje de programación real como Ruby y hacer SQL a través de él en lugar de Excel ... eso en sí mismo es una victoria.

Sólo mis 2 centavos.

Answer 3

Si está escribiendo sus consultas a mano, tiene la posibilidad de optimizarlas. Cuando miro esa consulta, veo cierto potencial para optimizaciones (E.ICGROUPNAME LIKE '% san-fransisco%' o E.ICGROUPNAME LIKE '% bordeaux%' no usará un index = Table Scan).

Al utilizar un OR Mapper (los Objetos/Tablas nativas) para informar, usted tiene poco o ningún control sobre la Querencia SQL resultante.

Pero: podría poner esa consulta en una vista o en un procedimiento almacenado y asignar ese View/Proc con un OR Mapper. Puede optimizar sus consultas y puede usar todas las características de su Marco de Aplicación.

Answer 4

En una situación así, probablemente me escribo a mano o utilizar una vista (si la base de datos que está utilizando soportes visitas)

Answer 5

A menos que usted está tratando con objetos, un ORM no es necesario . Parece que tu amigo simplemente necesita generar informes, en cuyo caso el SQL puro está bien siempre y cuando sepa lo que está haciendo (por ejemplo, evitando problemas de inyección de SQL).

ORM significa "Asignación relacional de objetos". Si no tiene la "O" (objetos), entonces probablemente no sea una buena opción para su aplicación. Donde realmente brillan los ORM es en objetos persistentes a la base de datos y cargarlos desde una base de datos.

Answer 6

Los ORM se utilizan cuando tiene objetos (objetos de negocio). Por lo tanto, supongo que tiene una aplicación con la que crea y administra los Business Objects que finalmente se guardan en la base de datos. Si es así, es casi seguro que haya obtenido una representación de las relaciones y, probablemente, muchos de los cálculos que va a utilizar en los informes. El problema con el uso de SQL para acceder directamente a su base de datos en busca de informes es simplemente mantenibilidad. Normalmente se esfuerza mucho para garantizar que sus Business Objects oculten los detalles de su base de datos. Implementa reglas de negocios y realiza cálculos comunes en sus Business Objects. Cree un lenguaje común para todos los miembros del equipo, etc. Luego use un ORM para mapear en la base de datos y use Habanero o NHibernate o algo así para hacer esto. Esto es genial Hacemos esto todo en nombre de la capacidad de mantenimiento y es genial. Puede migrar su aplicación cambiar su diseño, etc.

Ahora va y escribe SQL para ejecutar informes a lo largo del tiempo tiene cientos de informes. En primer lugar, a menudo duplican la lógica que ya tiene en sus BusinessObjects (por lo general sin ninguna prueba) y lo que es peor Bham Damb ahora se rellena el mantenimiento. Olvídese de mover un campo de una tabla a otra; olvídese de dividir esa tabla en dos cambiando esa relación, etc. tener una serie de informes que se van a romper inesperadamente.

El problema con la búsqueda de Domain Objects/Business Objects es simplemente uno de rendimiento.

En resumen, si utiliza los conceptos de Diseño impulsado por dominio u Objeto comercial, intente utilizarlos para los informes. (Probablemente se ejecutará directamente desde DB utilizando SQL o procs almacenados por razones de rendimiento, pero intente limitarlos, use primero sus Business Objects y luego use SQL). La otra opción, por supuesto, es utilizar una base de datos de informes separada (como algunos de los conceptos de BI). La asignación de su base de datos transaccional a su base de datos se encuentra en un solo lugar y puede cambiarse fácilmente en los casos en que desee cambiar su diseño.

Los objetos de dominio (Business Objects) y los ORM tienen todos los conocimientos para permitirle comenzar a generar consultas de alto rendimiento que se ejecutan directamente en la base de datos al usar la terminología de dominio. Esperemos que estos continúen evolucionando hasta el punto en que esto sea una realidad.

Hasta entonces, si está utilizando Business Objects en su aplicación intente utilizarlos para informar cuando el rendimiento es un problema recurrir a SQL.