Comparaciones de bibliotecas para SQL dinámico en Java

Question

Considere un servicio de solo lectura que necesita realizar una búsqueda en tiempo real de una base de datos de respaldo. El servicio debe ser capaz de generar consultas de selección bastante complejas para generar resúmenes, informes y resultados basados ​​en objetos de varias tablas. Las prioridades para la selección de biblioteca/marco son rendimiento (de sql), mantenibilidad y longevidad.

Hibernate - parece requerir "trucos" para conseguirlo para generar el SQL correcto, el API Criterios parece prometedor, pero también tiene varias limitaciones cuando se trata de consultas arbitrarias.

MyBatis - No hay API similar a Criteria pero es clara y limpia y, a menudo no requiere los trucos y tweeks de Hibernate. Limitada abstracción de la base de datos.

Algunas otras soluciones que aún no se han evaluado incluyen: SQLBuilder, Squiggle, Querydsl, JOOQ o una solución personalizada.

Lo que han encontrado los usuarios de SO funciona mejor para hacer un servicio de búsqueda rápido y versátil.

[Actualización] - Algunos de los trucos y los problemas que he enfrentado con Hibernate son ...

• https://hibernate.onjira.com/browse/HHH-879
• https://hibernate.onjira.com/browse/HHH-5291
• How to apply Where clause to secondary table
• https://forum.hibernate.org/viewtopic.php?f=1&t=973514

En general, joi a la misma mesa dos veces parece causar problemas. Incluso he logrado engañar a Hibernate para que produzca el SQL correcto solo para que correlacione los resultados incorrectamente porque almacenó en caché la primera instancia de la entidad y asumió que las columnas de la segunda unión eran redundantes. Las uniones condicionales expresadas a través de anotaciones también son dolorosas. No digo que sea imposible, pero muy críptico y no intuitivo.

Para responder a X-Zero a continuación, quiero pasar de una especificación a un resultado. Es decir, el consumidor me dice lo que sabe y creo una consulta que responde su pregunta sobre la marcha. En la práctica, pretendo tener algunos límites sobre lo que pueden pasar.

Answer 1

Para un servicio orientado a consultas, le recomiendo que se mantenga alejado de Hibernate o marcos JPA similares. MyBatis puede ser una buena opción y proporciona un soporte básico de secuencias de comandos para construir dinámicamente consultas a partir de fragmentos de SQL, pero tendrá que lidiar con dialectos SQL usted mismo.

Además, para agregar a su lista, también hay Spring SQL Template clases y JDBI, aunque ninguno de ellos soluciona el problema con los dialectos de SQL.

Answer 2

Según sus requisitos, creo que jOOQ sería una buena combinación. También mencionó jOOQ como uno de los marcos posibles, por lo que vamos a considerar sus necesidades desde la perspectiva de jOOQ:

El servicio tiene que ser capaz de generar bastante complejas consultas de selección

jOOQ modelos SQL como un lenguaje interno específico de dominio en Java.Esto significa que SQL (o algo que se ve casi como SQL) se construye usando objetos y métodos Java. Recientemente publiqué en mi blog sobre cómo se construyó la API DSL/fluent de jOOQ y por qué permite la construcción segura de tipos de consultas arbitrariamente complejas. Ver el blog aquí (incluyendo una consulta bastante compleja):

http://blog.jooq.org/2012/01/05/the-java-fluent-api-designer-crash-course/

para generar resúmenes, informes y resultados basados ​​en objetos multi-mesa.

jOOQ abraza características OLAP avanzadas utilizadas para generar resúmenes, informes, etc. soportados características incluyen GROUPING SETS (CUBE(), ROLLUP()), tablas dinámicas, consultas jerárquicas, funciones de ventana, y SQL arbitrario.

Las prioridades para la selección de la biblioteca/marco son el rendimiento (del sql),

jOOQ genera SQL de la manera que lo escribe.

mantenimiento

barcos jOOQ con un generador de código fuente modelar el esquema de base de datos como código Java. Esto es similar a lo que Hibernate y/o QueryDSL son capaces de hacer. Cuando su esquema cambia, su código Java cambia (lo que puede dar como resultado errores de compilación)

y longevidad.

jOOQ es maduro y tiene una descarga anual de 10k, creciendo. La API ha sido muy estable a través de las versiones anteriores.

Hibernate - parece requerir "trucos" para conseguirlo para generar el SQL correcto, el API Criterios parece prometedor, pero también tiene varias limitaciones cuando se trata de consultas arbitrarias.

Hibernate genera HQL (o JPQL), no SQL. No puede hacer un uso completo de las características de SQL con Hibernate.

MyBatis - API sin criterios, pero es clara y limpia y, a menudo no requiere los trucos y tweeks de Hibernate.

Esa es una buena opción, también, por lo que la intención que tenga

abstracción de base de datos limitada.

La API de jOOQ es la misma para cada base de datos subyacente. El SQL generado se ha probado en comparación con 13 RDBMS principales. Esto incluye una variedad de funciones, que se traducen y/o simulan en otras bases de datos.Un ejemplo de esto se da en esta entrada del blog, donde se describe la simulación de la cláusula de MySQL ON DUPLICATE KEY UPDATE en otros RDBMS:

http://blog.jooq.org/2012/05/01/how-to-simulate-mysqls-insert-statement-extensions/

O lo difícil manejo correcto de DUAL tablas puede ser:

http://blog.jooq.org/2011/10/16/sql-trouble-with-dummy-tables/

Descargo de responsabilidad: Soy el desarrollador de jOOQ, por lo que esta respuesta puede ser un poco parcial.