Entrevista a Fernando Guerrero

Fernando Guerrero está considerado uno de los mayores expertos mundiales en SQL-Server y tecnologías de bases de datos. Con un currículo tan largo como la lista de novedades de Windows 2003, suele ser invitado de honor a los eventos Microsoft, y aprovechamos que le gusta mezclarse con el pueblo llano, para hacerle una entrevista en la zona de MVP's del Tech-Ed. Además de hablar de las buenas y malas prácticas de programación en los sistemas de bases de datos, nos dio algunas pautas sobre su visión de futuro, y nos anticipó algunas de las novedades de la próxima y revolucionaria versión de SQL-Server: Yukon.

M. Posadas: Estamos con Fernando Guerrero, el speaker español de mayor proyección internacional, habitual en los Tech-Ed y otros macro-eventos de Microsoft. Fernando, ¿Cuál es tu actividad habitual?

F. Guerrero: Bueno, es un poco difícil, es una mezcla de consulting y formación, además de escribir, que puede ser preparar manuales, libros, artículos, borradores, etc.

M. Posadas: Tu último libro es sobre SQL-Server 2000, ¿no?

F. Guerrero: Sí, eso fue en 2001.También colaboro a veces con otros autores, haciendo revisiones técnicas de los libros. Ahora estamos diseñando una serie de libros que vamos a escribir para Yukon, la siguiente versión de SQL-Server.

M. Posadas: Tu has estado viviendo en Inglaterra 4 años, y ahora te has trasladado a España, según me comentabas el otro día en al cena...

F. Guerrero: Sí, desde el mes de Enero estamos en Torrevieja (Alicante).

M. Posadas: Bien, pues vamos a hablar de tu especialidad, que son las bases de datos y especialmente SQL-Server, y su conexión con ADO.NET. Lo primero que quería comentarte es la sensación inicial que mucha gente tiene cuando le hablas de ADO.NET y en concreto del Dataset, se asusta al pensar que tienes que traerte toda la base de datos al caché local. ¿Qué les comentarías tú al respecto?

F. Guerrero: Pues que siempre y cuando sean conscientes de las limitaciones, no supone ningún problema. El hecho de estar permanentemente conectado a una base de datos para cada una de las operaciones, parece, en principio, que es óptimo, pero la verdad es que no escala muy bien. Cuando tienes muchas conexiones, de las que alguna puede decidir no confirmar los cambios, eso supone una sobrecarga enorme del servidor. Mientras que utilizar algo que está desconectado, como es un Dataset, que utiliza memoria del cliente, te permite ver los datos al ritmo que tu quieras, y luego confirmar o desechar los cambios: es mucho más interesante.

Lo que no es aceptable es la posición de algunos que piensan que ese Dataset es una especie de ventana de tus datos, ya que dinámicamente pueden moverse a través de ellos, etc. Y por tanto no les asusta hacer un SELECT * que recoja toda la información del tirón, sin ninguna cláusula WHERE, sin ningún filtro de columnas, introduciendo un tráfico de red totalmente innecesario, y una utilización de memoria terrible. Especialmente cuando se trata de aplicaciones Web, existe en ocasiones el error de pensar que el cliente de SQL-Server es el que recibe las páginas, cuando el cliente en ASP.NET es IIS. Claro, si tienes un montón de aplicaciones simultáneas y cada una de ellas tiene que crear un Dataset, y te ocupa 1Gb. de espacio en memoria, eso es una locura...

El otro problema típico es que hay muchos que creen que es mejor filtrar en el lado del cliente, se traen toda la información "por si acaso", y luego deciden más tarde qué es lo que necesitan y cómo filtrar las filas y demás...cuando lo que deben hacer es justamente lo contrario. Debes de saber exactamente qué información necesitas y pedirle a la base de datos esa información nada más. Si necesitas más información pues se la pides. Pero es siempre más interesante pedirle 4 columnas y 18 filas ahora y otras 12 columnas y 35 filas más tarde que pedirle un millón de filas...por si acaso.

M. Posadas: Los otros comentario típicos que surgen en muchas ocasiones, son del tipo "yo tengo una base de datos con 3 millones de registros, ¿cómo voy a traerme eso al cliente?" o también la integridad de los datos en el servidor, diciendo "entonces si yo hago cambios en local, ¿quién me dice a mí que los datos que estoy viendo son los que estaban cuando comencé la operación?". ¿Qué comentarías tú a eso?

F. Guerrero: Bueno, para eso, cualquier sistema de base de datos ya implementa un bloqueo predeterminado y un control de cambios, para evitar conflictos. Por ejemplo, si seguimos lo que hace el Dataset, vemos que lleva un control de cuales eran los datos originales, cuándo se leyeron, y cuáles son los datos finales que tienes tú. Entonces, si tienes un DataAdapter en este caso, tu mandas el Dataset al DataAdapter, y este puede determinar qué filas son las que hay que actualizar en la base de datos. De ese modo lo que estás haciendo es un sistema de concurrencia optimista, en el cual, cuando tú leíste los datos, en ese momento tuviste unos bloqueos, pero una vez que desconectas el bloqueo desaparece. Por lo tanto depende de tu transacción, y la transacción depende de la conexión,  y la conexión ya no existe, Cuando te vuelves a conectar, tienes que crear una nueva conexión, crear una nueva transacción, y aplicar los cambios. Si no controlas, que los datos de la BB.DD. son iguales que los originales, podrías sobrescribir información correcta. El DataAdapter lo implementa automáticamente, de forma que compara los valores existentes con los valores antiguos. Como establece una comparación exacta, si el dato que se va a cambiar no coincide con el original, no actualiza ninguna fila. Simplemente lo ignora. Si no se usa el DataAdapter, es labor de la aplicación de cliente realizar esa verificación.

El problema es que hay casos en que las aplicaciones están mal diseñadas y tienen conflictos innecesariamente. Por eso es bueno diseñar las aplicaciones de modo que ese tipo de conflictos se eviten lo máximo posible. Por ejemplo, si dos conexiones distintas están accediendo al mismo registro y van a actualizar, ahí no hay remedio, el último que escriba es el que vale. Pero, incluso en esos casos puede hacerse algo.

Hay una aplicación muy interesante de Jesús López (SQLRanger), sobre otro sistema de concurrencia, de forma que él implementa un Adapter que llama SQLAdapter, con otra forma de concurrencia optimista. Lo que hace es que si dos conexiones distintas afectan a una tabla, el Adapter te permite que seas tú el que determine si eso es un conflicto o no. O utiliza el timestamp de esa fila para determinar la acción sin necesidad de comparar todas.

M. Posadas: ¿Qué puedes decirnos de lo que se llama generalmente "buenas prácticas", tanto en el diseño como en el acceso a las bases de datos.? O Dicho de otro modo, ¿cuáles son como consultor, los grandes defectos que te sueles encontrar en aplicaciones reales?

F. Guerrero: Uno de los defectos fundamentales suele ser una mala comprensión de cómo funcionan los bloqueos, lo que supone que la gente bloquee más de la cuenta. Y otro de los problemas típicos es un mal uso de componentes manejados por COM+. No se dan cuenta de que esos componentes inician transacciones automáticamente, en modo serializable, y bloquean todo absolutamente, hasta que se cierra la transacción. Eso hace que muchas otras conexiones estén simplemente esperando a que esos recursos se queden disponibles otra vez. De forma que ves casos en los que no hay nada malo en la optimización de las consultas, los índices son adecuados, pero ves que el tiempo de respuesta es terrible, precisamente, por que están produciendo bloqueos.

En más de un caso he visto clientes que están planteando gastarse millones de dólares en un nuevo sistema, por que no tenían rendimiento suficiente, cuando realmente lo que tienen que aplicar es el sentido común e implementar los bloqueos como Dios manda. De hecho, en este caso, bajaron de un tiempo de respuesta de minutos a varios segundos solamente, cambiando el nivel de aislamiento de los bloqueos. Así que una sola instrucción, que la escribes en unos pocos segundos, y se ahorraron 3 millones de dólares.

M. Posadas: Te refieres, naturalmente, al ISOLATION LEVEL, de SQL-Server...

F. Guerrero: Efectivamente. Ese es uno de los casos. Otras cosas que he visto, sobre todo en .NET es el mal uso de las instrucciones de consulta. Hay mucho SELECT *, mucho SELECT sin una cláusula WHERE, e incluso vemos como a veces leen tablas individualmente al Dataset y luego las unen dentro del Dataset. Eso no produce más que una penalización del rendimiento. Otras veces utilizan los Datasets cuando no es en absoluto necesario. En muchos casos, un DataReader puede darte mucho más rápidamente lo que quieres, sin esos problemas.

¿Qué mas podría añadir en cuanto a esto? Pues intentar implementar lo máximo posible del lado del servidor. Otro de los fallos que me he encontrado en muchas aplicaciones es que tiene instrucciones T-SQL en toda la aplicación. Te vas a la capa de presentación y tienes por todos los lados instrucciones SELECT, instrucciones UPDATE, etc. Todo eso, no pertenece a la capa de presentación. Nunca debería de estar ahí. Debería estar en el lado del servidor. De esa forma mejorarías la capacidad de mantenimiento considerablemente, por que tienes un solo punto donde tienes que ir a actualizar. Muchas veces, optimizar una aplicación requiere optimizar la estructura del mantenimiento: donde originalmente tienes una tabla, te encuentras con que ofrece más rendimiento crear varias tablas y gestionarlas mediante vistas. Eso lo puedes hacer a veces transparentemente, siempre y cuando tengas la facilidad de hacer todos los cambios en la base de datos y que los clientes solamente llamen a través de otras estructuras de datos, como procedimientos almacenados, o vistas, o funciones de usuario.

M. Posadas: Ahora que hablas de funciones de usuario, aprovecho para comentarte que creo que es uno de los grandes desconocidos a nivel popular respecto a SQL-Server 2000.

F. Guerrero: Yo respecto a eso me he encontrado los dos extremos. Los que las ignoran por completo, y casi no saben de qué van, y gente que las usa demasiado. O las utilizan en sitios donde no se deberían utilizar. Por ejemplo hay casos en que la gente las utiliza en definiciones de CONSTRAINTS o cosas así, o incluso en subconsultas, pero lo hacen de tal modo, que la función se tiene que ejecutar para cada una da las filas...

M. Posadas: Como los viejos Cursores...

F. Guerrero: Exacto. A veces hablamos de tablas de 1 millón de filas unidas con otras similares, que pueden producir un millón de llamadas a la función en cada lado, cuando debería de haber otro sistema mejor...  Yo las veo muy útiles para casos como en los que se necesitan unas consultas a vistas con parámetros. Pues hay un tipo de función que te ofrece exactamente eso. Otras veces necesitas una función escalar que convierta una serie de valores de columnas en un dato determinado. Pues la puedes definir como quieras. Y la puedes integrar en valores por defecto, o en columnas de una consulta...

M. Posadas: Incluso las hay que devuelven un conjunto de registros...

F. Guerrero: Eso es otro tipo, sí. Se parecen mucho a los procedimientos almacenados. Ahora bien, se trata de un tipo especial de procedimiento almacenado, cuyo único resultado al final es un conjunto de registros. A veces es algo confuso, porque tienes 3 estructuras completamente distintas, con funcionalidades distintas, definiciones distintas, etc., y a todas ellas las llamamos funciones definidas por el usuario. Cuando hubiera estado más claro si las hubieran denominado con nombres distintos: funciones escalares, vistas parametrizables, y funciones de conjunto de registros.

Se trata de darles el uso adecuado. Yo las utilizo mucho y en particular, hay muchos procedimientos del sistema que los convierto en funciones del sistema, para tener una disponibilidad especial,. De hecho, en algunos casos, ellos mismo lo han hecho respecto a la versión anterior.

Con Fernando, en un momento de la entrevista (en la sala de MVP's)

M. Posadas: Bueno, y el futuro es Yukon, ¿no?. He tenido ocasión de ver una de las presentaciones sobre él. ¿Qué es lo que nos puedes decir que se haya hecho público sobre este producto?

F. Guerrero: Bien, lo único de lo que podemos hablar es lo que Microsoft ha publicitado hasta ahora. Hay un par de cosas que son las que han motivado los cambios en Yukon: Una es la integración con Visual Studio, de forma que ambos productos, aparecerán como absolutamente compatibles entre ellos. Visual Studio utilizará Yukon, como base de datos por defecto, y Yukon utilizará Visual Studio como entorno de programación por defecto, y utilizara los lenguajes de éste como lenguajes por defecto, también. Eso no quiere decir que los únicos lenguajes sean esos sino que Yukon podrá utilizar eventualmente Visual Basic .NET o C#, etc. Pero, evidentemente, el lenguaje T-SQL que es que está definido para el tratamiento de conjuntos de registros, seguirá ahí, e incluso potenciado, como podrá comprobarse. Habrá muchísimas mejoras en T-SQL.

Habréis oído hablar de que SQL-Server va a ser el que gestione el sistema de ficheros de la nueva versión del sistema operativo (Longhorn), que va a manejar Active Directory, etc. Y SQL-Server tal y como está ahora no es capaz de hacer eso. Luego, eso supone que hay una serie de cambios que se tienen que aplicar al producto, para que, el día de mañana cuando aparezca la nueva versión, todos estos sistemas estén integrados. Hay cambios que aplicar a Windows, a Exchange, incluso a Office, y hay cambios que aplicar a SQL-Server. Por eso están trabajando conjuntamente para que esos cambios se produzcan. Ahora están desarrollando un Framework que funcione dentro de SQL-Server, y que pueda permitir el funcionamiento de Assemblies o de Servicios Web dentro de SQL-Server, directamente.

M. Posadas: o sea, que va a ser un SQL-Server mucho más programable para los usuarios, incluso a bajo nivel...

F. Guerrero: Eso es. Desde mi punto de vista personal, si por ejemplo analizas cómo se puede interactuar con un objeto externo hoy en día desde SQL-Server, tienes ahora mismo básicamente dos posibilidades: una es crear un procedimiento extendido, que interactúe con ese componente por un lado, y por otro que interprete SQL-Server. Esa una de las formas en las que el propio SQL-Server está implementado a la fecha de hoy. Otro modo es utilizar los procedimientos sp_oa (upgrade/destroy, etc) que lo que te permiten es que desde un script de T-SQL puedas llamar a un componente externo e interactuar con él. Si dentro de Yukon vas tener el motor de .NET Framework, esas dos posibilidades se quedan un poco obsoletas. No quiere decir que vayan a desaparecer, sino que no serán necesarias. No necesitaré ningún tipo de envoltorio para ello.

Otra de las características que han motivado los cambios en Yukon, es, fundamentalmente, un cambio de mentalidad en Microsoft, en cuanto al papel que juega SQL-Server en la industria. Ellos son perfectamente conscientes de que SQL-Server está empezando a trabajar muy bien en grandes proporciones, y quieren una herramienta potente, que requiere cambios a nivel de disponibilidad, de escalabilidad, etc. Esos son para mí los dos motores que están provocando estos cambios. Luego, hay muchas mejoras en otros aspectos, en cuanto a programabilidad, en almacenamiento de datos, hay nuevos tipos de datos, en fin, hay muchos cambios en esos aspectos. En otro orden de cosas, hay cuestiones que no han cuajado como se pensaba en la versión 2000. Por ejemplo, se ha visto que las vistas distribuidas (...Eladio Rincón nos recordaba en este momento que se tradujeron por particionadas...) pues son difíciles de manejar, de forma que para la próxima versión han redefinido esas y otras cuestiones para hacerlas más fáciles de programar, y a la vez, más potentes.

M. Posadas: Otra cuestión importante, tiene que ver con la integración del SGDB con el sistema operativo, en este momento Windows 2003.¿Crees que se potencian de alguna forma también algunos de los servicios básicos del sistema con esta nueva versión?

F. Guerrero: Así es. Si pensamos en lo que ocurrió con la versión anterior, nos damos cuenta que ya había un paralelismo entre Windows 2000 y SQL-Server 2000. Las configuraciones de los ordenadores que estaban disponibles en aquel momento no eran como los de ahora. La velocidad de procesamiento se ha multiplicado por 3 ó 4, incluso tenemos máquinas de 64 bits que tiene 256 Gb de RAM, o servidores con 32 procesadores como algunos modelos de Unisys y eso era impensable entonces. De forma que Windows ha tenido que evolucionar con el hardware disponible para jugar un nuevo papel en la corporación. Tiene que ser más estable, tiene que manejar los recursos más eficientemente, tiene que ser capaz de trabajar en modo cluster de forma más eficaz y segura, y de todo eso, SQL-Server obtiene ventajas.

Una de las ventajas en este aspecto, es, precisamente, que SQL-Server no tiene que implementar esa funcionalidad, Eso ya lo implementa Windows. A veces se me pregunta ¿Cuantos nodos en un cluster soporta SQL-Server? La respuesta es: los que soporte Windows. De hecho es muy posible que sólo funcione en las nuevas versiones de Windows y no soporte las antiguas, precisamente por esto. De hecho, en algunas pruebas que hemos hechos con algunos clientes, hemos visto que SQL-Server 2000 sobre Windows 2000, tenían un cierto nivel de rendimiento, y al trasladar ese software a Windows 2003, y el rendimiento ha mejorado enormemente. Solamente por cambiar al nuevo sistema. Eso les ha permitido retrasar las inversiones en servidores, reutilizando el hardware que ya tenían, gracias al cambio del sistema.

M. Posadas: Hace unos años, en una entrevista a Tony Goodhew, le pregunté por las bases de datos orientadas a objetos. Sobre si tenían futuro o no. El me dijo que -en ese momento- no. ¿Crees que la situación ha cambiado o sigue igual?

F. Guerrero: Es una idea muy bonita, pero el problema, es cómo lo llevas a la práctica: tener muchos objetos en memoria, cada uno con su funcionalidad podría ser muy interesante, con una mezcla de datos y aplicación, está muy bien...en teoría. En la práctica, cuando tenemos que manejar varios millones de objetos nos encontramos con barreras prácticamente insalvables. ¿Cómo buscas eficientemente a través de todos esos objetos? ¿Cómo creas un índice que permita el acceso rápido a todos esos objetos? Parece muy difícil por el momento. Al final, a lo que el mercado está tendiendo ahora es a tener una implementación física como base de datos relacional, pero luego tienen una capa lógica encima, que implementa ese modelo de objetos, que enmascara la realidad, que es únicamente relacional.

Si comparamos una búsqueda binaria, con índices, etc., con búsquedas en otros tipos más complejos, y a no ser que la implementación sea exquisita, tanto en términos de diseño como de implementación, no se produce ningún rendimiento bueno. Utiliza demasiada memoria y actualmente, las implementaciones que hay en el mercado, no acaban de tener aceptación. Y los productos comerciales que ha habido hasta ahora en BB.DD. orientadas a objetos no han funcionado bien comercialmente. A veces, la mejor solución es impracticable, y es preferible una buena solución, bien conocida, y sobre la que podemos actuar con más conocimiento de causa. A fin de cuentas, lo que quiere una gran corporación es dar servicio a sus clientes, si es posible, con el mismo dinero y el mismo esfuerzo, y eso, hoy por hoy, lo están dando las bases de datos relacionales.

Incluso, si pensamos en la comparación con mainframes, que disponen de bases de datos jerárquicas, las pruebas indican que se están consiguiendo rendimientos mucho mejores hoy en día, con las relacionales, por una fracción del costo de los mainframes. Resumiendo, a mí entender, yo no implementaría una base de datos orientada a objetos ahora mismo. De hecho una de las primeras cosas que preguntamos a Microsoft, cuando empezaron con Yukon, fue precisamente, eso, y la respuesta era tajante: no. En el futuro, ¿quién sabe? puede haber nuevas líneas de investigación, que lo permitan pero, al día de hoy, no lo veo factible.

M. Posadas: O sea, que confirmas la impresión que Tony nos dio hace un par de años...Bien, pues gracias por este rato tan interesante, y esperemos que volvamos a coincidir en un próximo evento.

F. Guerrero: Seguro que sí. Muchas gracias a vosotros.