SQL es un lenguaje tan viejo como la mayoría de nosotros. Sin embargo cada 6 meses aparece un sustituto que pretende estandarizar el eterno problema del SQL nativo. HQL con sus dialectos, myBatis con sus SQL’s parametrizadas incrustadas, OQL con sus “flavors” que nos devuelve al problema original y te deja como al principio.

Como ingenieros, no debería preocuparnos que lenguaje están usando actualmente en un proyecto, sino que decisiones técnicas soportaron ese uso y la conveniencia de mantenerlo en un futuro. El uso de Criterias no va a perjudicar la mantenibilidad de una aplicación, pero el copy-paste de Criterias sí que puede generar un peligroso código espagueti.

Quizas te han dicho que el LQL (“loquesea” query language) es el futuro, pero después de 5 o 6 años dando vueltas con el mismo tema quizás acabemos dándonos cuenta de que intentar estandarizar lo que no se deja estandarizar no termina de ser rentable.Y pocos proyectos comerciales usan dichos lenguajes con exito:

Tristemente son pocos los proyectos los que se benefician de la portabilidad de BBDD… eso sí, los que se benefician, se ahorran una cantidad de problemas tremenda, como es el estar pagando licencias de BBDD de por vida ¿no nos interesará a todos entonces esa portabilidad?.

Incluso todavía hay gente defendiendo la bondad de los procedimientos almacenados para contener la lógica de la aplicación “en alguna” circunstancia… ¡cosas veredes!.