Estos días fueron de análisis acerca de las caráterísticas de SQL Server, en especial las versiones 2005 y 2008, que sí molestan cuando se habla de un framework que genera código hacia múltiples motores relacionales, el actual framework en cuestión NHibernate, otros, pueden unirse a la queja.

Siempre en el núcleo de NHibernate hay que aplicar parches para las propias características de los motores relacionales que soporta, lo cual es muy entendible, cada motor tiene derecho a implementar como cree que es mejor sus características. Muchos de esos cambios desembocan en el dialecto, otros en el parser, otros en la parametrización o preparación de los commandos a ejecutar (lease IDbCommand) y otros vaya uno a saber.

Algunas características que implicaron cambios a pedido de los usuarios, tanto en dialecto como en parsers son entre otros: la paginación! Esta característica de SQL Server dio qué hablar, y mucho dolor de cabeza.

Cómo algo tan básico, que se usa día a día en las aplicaciones que desarrollamos, y hasta pareciera inofensivo, terminó desembocando en TODO un cambio en el dialecto de MsSql2005 (dentro de NHibernate por supuesto).

Qué hicimos los usuarios de Sql Server 2005/2008 para recibir semejante fea característica de paginación? Quizás no haya ejemplos de otros de otros RDBMS con paginación?, quizás no fuimos tan devotos del producto? Vaya uno a saber. Pero ejemplos de paginación en otros RDBMS. Este Sr. Postgres hace una linda paginación con la clausula LIMIT, donde se declara el límite y el offset. Fácil no? Resumiendo, esta característica se salvó aplicando un parche grande al dialecto gracias a contribuidores.

Compliquémosle un poco cuando usamos Sql Server 2005/2008 con las clausulas de FullText Search nativas: Contains y FreeText. Ambas clausulas hasta parecen mágicas por que son ?void?, no devuelven ningún valor, y esto significó otro parche en el Parser de NHibernate, uno chico, pero modificamos el Parser (no el Dialecto del motor específico), lo cual lo hace un poquito más molesto, porque? Por que el dialect es una de las cosas más recomendadas a inyectar cuando se trata de características que faltan. Para ver cómo terminaron las cosas, ir a este post.

Ahora vayamos a Queries Parametrizadas + Planes de ejecución. Bueno, todos saben es extremadamente bueno que el RDBMS cachee los planes de ejecución de las consultas para poder usarlas más tarde, ganando en performance. Incluso muchos usan SP por que dicen que NHibernate: ?genera consultas dinámicas que desembocan en el recalculo del plan de ejecución de cada consulta?. Esto es FALSO. NHibernate genera consultas, pero son todas parametrizadas, por lo tanto son reusables para no volver a calcular los planes de ejecución. Inclusive NHibernate se vale de opciones como: ?prepare_sql?, que sirve para activar el comando Prepare() en el IDbCommand. El punto es el siguiente, ahora Sql Server 2008 lanzó otra característica que le agrega otro pedazo de código a nuestras consultas SQL: OPTIMIZE FOR UNKNOWN. Podemos tomar un pequeño paseo por esta característica leyendo este post. La característica me parece bárbara, pero, otro pedazo más de SQL para eso?

No quiero saber a donde vamos a parar de acá a 10 años: O se empiezan a hacer más transparentes algunas opciones importantes, o cuando tenemos algún framework que genera código SQL para nuestro motor SQL Server vamos a necesitar impresiones en algo más que formato A4 para leer.

Quizás, quien dice, haga falta una re-estandarización del lenguaje SQL, por que nos estamos pasando con ?nuestras? propias implementaciones, y ese tipo de cosas perjudican a las herramientas (frameworks) que trabajan sobre estos motores para hacer las cosas más fáciles a los desarrolladores.