sql - que - orm c#

Cuándo utilizar un ORM(Sequel, Datamapper, AR, etc.) frente a SQL puro para realizar consultas

Question

Un colega mío está diseñando actualmente consultas SQL como la que se muestra a continuación para producir informes, que se muestran en archivos de Excel a través de una consulta de datos externa. En la actualidad, solo se requieren procesos de informes en la base de datos (no operaciones CRUD).

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

A pesar de las ventajas obvias de mostrar los datos, ¿qué ventajas tiene para él aprender a usar un ORM como Sequel o Datamapper?

Las consultas de SQL que está escribiendo son bastante complejas, y al ser relativamente nuevo en SQL, a menudo se queja de que es muy confuso y requiere mucho tiempo. ¿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 los dbs heredados)? y ¿cuáles son las ventajas de aprender ruby ​​y usar un ORM en lugar de quedarse con SQL simple en la realización de consultas de bases de datos complejas?

Answer 1

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

ORM significa "mapeo objeto-relacional". 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 en la base de datos y cargarlos desde una base de datos.

Answer 2

En una situación como esa, probablemente las escribiría a mano o utilizaría una Vista (si la base de datos que está usando admite vistas)

Answer 3

Los ORM se utilizan cuando tiene Objetos (Objetos de negocio). Por lo tanto, asumo que tiene una aplicación con la que está creando y administrando los Business Objects que finalmente se guardan en la base de datos. Si es así, es casi seguro que tiene alguna 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 para informes es simplemente la capacidad de mantenimiento. Por lo general, se esfuerza mucho para garantizar que sus Business Objects oculten cualquier detalle de su base de datos. Implementas reglas de negocio y haces cálculos comunes en tus objetos de negocio. Cree un lenguaje común para todos los miembros del equipo, etc. Luego, utilice un ORM para asignar a la base de datos y use Habanero o NHibernate o algo así para hacer esto. Todo esto es genial. Hacemos todo esto 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 con el tiempo que tiene cientos de informes. En primer lugar, a menudo duplican la lógica que ya tiene en su BusinessObjects (por lo general sin ninguna prueba) y, lo que es peor, Bham Damb. Lo siento, la capacidad de mantenimiento ahora está repleta. Olvídese de mover un campo de una tabla a otra. tener una serie de informes que se van a romper inesperadamente.

El problema con las preguntas a través de sus Objetos de Dominio / Objetos de Negocio es simplemente uno de rendimiento.

En resumen, si está utilizando los conceptos de Diseño impulsado por dominio o Objeto de negocio, intente usarlos para los informes. (Probablemente ejecutará directamente desde la base de datos utilizando SQL o procesos almacenados por razones de rendimiento, pero intente limitarlos; primero use su 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 de informes está, por lo tanto, en un 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 todo el conocimiento para permitirle comenzar a crear consultas de alto rendimiento que se ejecutan directamente en la base de datos mientras usa la terminología de dominio. Esperemos que estos continúen evolucionando hasta un punto donde esto sea una realidad.

Hasta entonces, si está utilizando Business Objects en su aplicación, intente usarlos para la generación de informes cuando el rendimiento es un problema para recurrir a SQL.

Answer 4

ORM significa Mapeo Relacional de Objetos - pero mirando la consulta, tu amigo parece querer una tabla bastante específica de sumas y otros artículos ... No he usado la Secuela de Ruby, pero he usado Hibernate y SQLAlchemy de Python (para Django / Turbogears) y si bien puedes hacer este tipo de consultas, no creo que esa sea su fortaleza.

El poder de ORM proviene de la posibilidad de encontrar relaciones entre objetos Foo-> Bar. Supongamos 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 "buena" solución, aunque pasaría a un lenguaje de programación real como Ruby y realizar el SQL a través de él en lugar de Excel ... eso en sí mismo es una victoria.

Sólo mis 2 centavos.

Answer 5

Si está escribiendo sus consultas a mano, tiene la oportunidad de optimizarlas. Cuando miro esa consulta veo un potencial de optimización (E.ICGROUPNAME LIKE ''% san-fransisco%'' o E.ICGROUPNAME LIKE ''% bordeaux%'' no utilizará un índice = Exploración de la tabla).

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

Pero: puede poner esa consulta en una Vista o Procedimiento almacenado y asignar esa Vista / Proc con un Asignador OR. Puede optimizar sus consultas y puede usar todas las características de su Marco de aplicación.

Answer 6

Soy el mantenedor de DataMapper, y creo que para informes complejos debería usar SQL.

Aunque creo que algún día tendremos un DSL que proporcione la potencia y la concisión de SQL, todo lo que he visto hasta ahora requiere que escribas más código Ruby que SQL para consultas complejas. Preferiría 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 integrados del 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 solo informan. Es posible que tenga muchas operaciones de tipo CRUD, para las cuales un ORM se adapta perfectamente y es mucho mejor que hacer esas cosas a mano.

Una cosa que un ORM normalmente proporcionará es algún tipo de organización para la lógica de su aplicación. Puede agrupar código basado en cada modelo en el mismo archivo. Por lo general, es ahí donde pondré la consulta SQL compleja, en lugar de incrustarla 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 solo puedo generar el informe usando User.some_complex_query . También puede insertar la consulta SQL en una vista si desea limpiar más este código.

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