Seguro que si, es más, yo creo que todos lo sabemos y sin embarlo lo seguimos utilizando … Ahora me viene a la cabeza (no recuerdo donde lo he leido, si era en las news o en alguna url) que alguien comentó algún día la NECESIDAD de quitar el asterisco (*) del lenguaje T-SQL. Por descabellado que parezca: nos cargarmos en ANSI-SQL (que ya falta muy poco para acabar con el), hacemos más costosos los desarrollos (vaya tela con tener que escribir siempre las columnas) y lo más importante la compatibilidad hacia atrás (backward compatibility) se destroza. Hombre, yo creo que poniendo una opción de configuración SET (eso sí por defecto activa, el que quiera que la desactive), más de un servidor lo iba a agradecer … y más de un desarrollador se tiraría de los pelos para hacerla compatible con el nuevo estandard ANTI_SELECT_ASTERISCO.
Bueno que me enrollo, habeis visto dos ejemplos básicos que casi todos conocemos, y sin embargo un alto porcentaje de los problemas de rendimiento vienen derivados de esos ejemplos.
¿y qué pasa ahora con Yukon? pues que Microsoft nos pone mucho más fácil la posibilidad de crear cursores en la propia base de datos con .NET. Uhhmmmmm No quiero decir que esté en desacuerdo: NI POR ASOOOOOMO ! No nos equivoquemos ! SQL Server es un servidor de base de datos que trabaja muy eficientemente orientado a juegos de registros ( set-based programming) sin embargo la inclusión de CLR dentro de la base de datos va a hacer renacer viejos hábitos orientados a fila …
Microsoft es consciente de ello y seguro que tiene preparada mucha documentación y ejemplos para no dejarnos caer en la tentación, pero es la pregunta de la primera frase: ¿haremos bien nuestro trabajo? ¿Pasará igual que con el asterisco?
