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

Question

Un colega mío está diseñando consultas SQL como la siguiente para producir informes, que se muestran en los archivos de Excel a través de una consulta de datos externos. En la actualidad, se requieren procesos solamente de informes sobre la DB (no hay operaciones CRUD).

Estoy tratando de convencerlo de que sería mejor usar un rubí ORM con el fin de ser capaz de mostrar los datos en un rieles / aplicación Sinatra.

A pesar de las ventajas obvias en la visualización de los datos, ¿qué ventajas tiene para él para aprender a usar un ORM como secuela o DataMapper?

Las consultas SQL que está escribiendo son claramente bastante complejo, y siendo relativamente nuevo en SQL, que a menudo se queja de que es muy lento y confuso. ¿Es posible escribir consultas extremadamente complejos con un ORM? y si es así, cuál es el más adecuado (Sequel He oído que es bueno para DBS legacy)? y cuáles son las ventajas de aprender rubí y el uso de un ORM frente a la pervivencia de SQL llano, en la toma de consultas de bases de datos complejas?

Answer 1

Soy el mantenedor DataMapper, y creo que para la presentación de informes compleja que debe utilizar SQL.

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

Tenga en cuenta que digo compleja .. si tiene algo simple, utilizar construir-en el ORM de buscadores. Sin embargo, yo creo que hay una línea donde se puede cruzar SQL se hace más simple. Ahora, la mayoría de las aplicaciones no son sólo un informe. Es posible que tenga una gran cantidad de operaciones de tipo CRUD, para los que un ORM se adapta perfectamente y mucho mejor que hacer esas cosas a mano.

Una cosa que un ORM suelen proporcionar algún tipo de organización a la lógica de la aplicación. Puede código de grupo en torno a 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

A continuación, sólo puedo generar el informe utilizando User.some_complex_query. También podría empujar la consulta SQL en una vista si quería continuar la limpieza de este código.

EDIT: Por "vista" en la frase anterior me refería a la vista de RDBMS, en lugar de la vista en el contexto de la MVC. Sólo quería aclarar cualquier posible confusión.

Answer 2

Si va a escribir sus consultas con la mano usted tiene la oportunidad de optimizarlos. Cuando miro a esa consulta veo algún potencial para optimizaciones (E.ICGROUPNAME LIKE%-San Fransisco% 'o E.ICGROUPNAME COMO 'burdeos%%' suele utilizar un índice = Tabla Scan).

Cuando se utiliza un Mapper O (los objetos nativos / Tablas) para informar de que tiene poco o ningún control sobre la consulta SQL resultante.

Pero: Se puede poner esa consulta en una vista o procedimiento almacenado y el mapa que se visualice / proc con un OR Mapper. Puede optimizar sus consultas y se puede utilizar todas las características de su marco de aplicaciones.

Answer 3

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

ORM es sinónimo de "Object-Relational Mapping". Si usted no tiene la "O" (objetos), entonces no es probablemente una buena opción para su aplicación. Donde ORM brillan realmente está en la persistencia de objetos de la base de datos y cargarlos desde una base de datos.

Answer 4

ORM significa Objeto Relational Mapping - pero mirando a la consulta a su amigo parece estar queriendo una mesa bastante específica de sumas y otros artículos ... No he utilizado secuela de Ruby, pero yo he usado Hibernate, y Python SQLAlchemy (por Django / TurboGears) y mientras que puede hacer este tipo de consultas, no creo que es su fuerza.

El poder de ORM viene de ser capaz de encontrar foo-> relaciones de objeto de bar, quiere decir que todos los objetos de barras para el campo de Foo mayores entonces X ... Ese tipo de cosas. Por lo tanto no clasificaría un ORM como una solución "buena", aunque se trasladen a un lenguaje de programación real como Ruby y hacer el SQL a través de él en lugar de Excel ... que en sí mismo es una victoria.

Sólo mi 2 centavos.

Answer 5

En una situación como esa, probablemente volvería a escribir a mano o utilizar una vista (si la base de datos que está utilizando vistas soportes)

Answer 6

ORM se utilizan cuando se tiene Objetos (Business Objects). Por lo tanto, estoy asumiendo que usted tiene una aplicación con la que la creación y administración de los objetos de negocio que son finalmente guarda en la base de datos. Si usted tiene entonces casi seguro que tienes alguna representación de las relaciones y probablemente muchos de los cálculos que se van a utilizar en los informes. El problema con el uso de SQL para acceder directamente a la base de datos de informes es simplemente el mantenimiento. Por lo general, pone mucho esfuerzo en asegurar que sus objetos de negocios Ocultar los detalles de su base de datos. Implementar reglas de negocio y hacer cálculos comunes en sus Business Objects. Construir un lenguaje común para todos los miembros del equipo, etc, etc A continuación, utiliza un ORM para asignar a la base de datos y utilizar Habanero o NHibernate o algo por el estilo para hacer esto. Esto es todo muy bien. Hacemos esto todo en nombre de la mantenibilidad y es grande. Puede migrar cambiar su aplicación de su diseño, etc, etc.

Ahora vaya y escribir SQL para ejecutar informes con el tiempo que tiene cientos de informe. En primer lugar que a menudo duplican la lógica que ya tiene en sus BusinessObjects (Por lo general, sin ningún tipo de pruebas) y peor aún bham Damb mantenimiento siento ahora se rellenan olvidarse de mover un dicho campo de una tabla a otra olvidarse de la división de la mesa en dos cambiar esa relación, etc se tener una serie de informes que se van a romper de forma inesperada.

El problema con quering a través de los objetos de dominio / Objetos de negocio es simplemente uno de rendimiento.

En resumen, si usted está usando Domain Driven Design o conceptos objeto de negocio tratan de utilizar estos para informes. (Es probable que ejecutar directamente desde DB utilizando SQL o procedimientos almacenados por razones de rendimiento, pero trate de limitar estos utilizan sus Business Objects, luego utilice SQL). La otra opción, por supuesto, está utilizando una base de datos de informes por separado (igual que algunos de los conceptos de BI) La asignación de su transaccional base de datos para su presentación de informes DB es, por tanto, en un lugar y fácilmente cambiable en los casos en los que desee cambiar su diseño.

Los objetos de dominio (Business Objects) y ORM tienen todo el conocimiento para que pueda empezar a construir consultas de alto rendimiento que se ejecutan directamente en la base de datos durante el uso de la terminología de dominio. Deja la esperanza de que éstos siguen evolucionando a un punto en que esto es una realidad.

Hasta entonces si está utilizando Business Objects en su aplicación intente usarlos para Reporting cuando el rendimiento es un complejo problema de SQL.