¿Vale la pena la asignación O/R?

Question

La expresividad de los lenguajes de consulta (QL) provistos con ORM puede ser muy poderosa. Desafortunadamente, una vez que tiene una flota de consultas complejas, y luego surge un problema de esquema o datos desconcertante, es muy difícil obtener la ayuda de DBA que necesita. Aquí están, parte del equipo que está desarrollando la base de datos, sin embargo, no pueden leer la aplicación QL, y mucho menos sugerir modificaciones. En general, termino capturando el SQL generado del registro para ellos. Pero luego, cuando recomiendan cambios, ¿cómo se relaciona eso con el QL original? El proceso no es de ida y vuelta.

Así que después de una década de promover el valor de los ORM, ahora me pregunto si debería escribir mi SQL manualmente. Y tal vez todo lo que realmente quiero que haga el marco es automatizar la recopilación de datos tanto como sea posible.

Pregunta: ¿Ha encontrado una forma de resolver el problema de ida y vuelta en su organización? ¿Existe un marco de referencia de SQL que se adapte bien y se mantenga con facilidad?

(sí, ya sé que pura SQL me podría enlazar con el proveedor de base de datos. Pero es posible escribir compatible con los estándares SQL.)

Answer 1

Creo que lo que quiere es una solución que maximice los beneficios de ORM sin impedir que use otros medios. Tenemos el mismo problema que usted tiene en nuestra aplicación; consultas muy pesadas y un gran modelo de datos. Dado el tamaño del modelo de datos, ORM es invaluable para la gran mayoría de la aplicación. Nos permite ampliar el modelo de datos sin tener que esforzarse mucho manteniendo manualmente las secuencias de comandos SQL. Además, y tocó esto, apoyamos a cuatro proveedores de bases de datos, por lo que la abstracción es agradable.

Sin embargo, hay casos en los que hemos tenido que sintonizar las consultas manualmente, y dado que elegimos una solución flexible de ORM, también podemos hacerlo. Como dices, se sale de nuestro camino cuando necesitamos que se vaya, y simplemente dirige los objetos para nosotros.

Así que, en resumen (sí, corto) sí, ORM vale la pena, pero como todas las soluciones a un problema, no es una panacea.

Answer 2

En general, ORM aumentan la productividad del desarrollador mucho, así que' d usándolos a menos que se hayan convertido en un problema mayor de lo que vales. Si la mayoría de las tablas son lo suficientemente grandes como para que tenga muchos problemas, considere abandonar el ORM. Definitivamente no diría que los ORM son una mala idea en general. La mayoría de las bases de datos son lo suficientemente pequeñas y la mayoría de las consultas son lo suficientemente simples para que funcionen bien.

He superado ese problema mediante el uso de procedimientos almacenados o SQL manuscrito solo para las consultas de bajo rendimiento. A los DBA les encantan los procedimientos almacenados porque pueden modificarlos sin decírselo. La mayoría (si no todos) de los ORM le permiten mezclar en forma manual SQL o procedimientos almacenados.

Answer 3

marcos de O/R de hoy, como creo que usted está familiarizado, admiten la opción de definir algunas consultas manualmente ((N) Hibernate lo hace). que se puede usar para partes complejas de esquemas, y para partes simples use el ORM según lo provisto por el marco.

Otra cosa que debe comprobar es el marco iBatis (http://ibatis.apache.org/). No lo he usado, pero he leído que está más cerca de SQL y las personas familiarizadas con las bases de datos y SQL lo prefieren sobre el marco ORM completo como Hibernate, porque está más cerca de ellos que el concepto completamente diferente de ORM.