Recursividad con Sql Server

Una función muy interesante de Sql Server es la de poder seleccionar un conjunto de datos de forma recursiva de manera que podemos obtener una serie de datos en estructura de arbol.

Partimos de una tabla que tiene dos campos, llamados clave y padre, el campo clave se relaciona con el padre para formar la estructura en arbol.

El siguiente procedimiento almacenado muestra un ejemplo de como conseguir esto:

ALTER PROCEDURE [dbo].[Usuarios_seguridad_seleccionar]

AS

BEGIN    

    DECLARE @minClave int

    SELECT @minClave = MIN(Clave) FROM dbo.Usuarios_seguridad;

    WITH UsuariosAccesos AS

    (

        SELECT top 1 us1.Padre,us1.Clave,us1.Variable,us1.Modulo,us1.Contenido,us1.Acceso,us1.Imagen 

        FROM dbo.Usuarios_seguridad us1 

        WHERE us1.Clave = @minClave

        UNION ALL

        SELECT top 100 percent us2.Padre,us2.Clave,us2.Variable,us2.Modulo,us2.Contenido,us2.Acceso,us2.Imagen 

        FROM dbo.Usuarios_seguridad us2 

        INNER JOIN UsuariosAccesos AS us3 ON us3.Clave = us2.Padre  

        WHERE us2.Clave <> @minClave 

    )

    SELECT TOP 100 PERCENT ia.Padre,ia.Clave,ia.Variable,ia.Modulo,ia.Contenido,ia.Acceso,ia.Imagen 

    FROM UsuariosAccesos ia

    ORDER BY padre, clave

END

GO

 

El procedimiento almacenado calcula el valor mínimo del nodo con la clave mas baja, posteriormente va leyendo cada nodo relacionado de forma recursiva ya que en el inner join se relaciona con el conjunto de datos definido en la clausula WiTH, finalmente devuelve el conjunto de datos en un orden determinado, el resultado obtenido es el siguiente:

De esta forma la consulta devuelve los datos de forma similar a la estructura de estos, posteriormente se cargan el tree.

Si quereis mas información sobre la clausula WITH que permite realizar este tipo de consultas podeis encontrala en http://msdn.microsoft.com/en-us/library/ms175972.aspx

Acelera Visual Studio con Discos Solidos (SSD) y Tarjetas de Memoria

Después de leer varios artículos sobre los últimos modelos de discos SSD, y con el fin de acelerar mi trabajo con Visual Studio decidí adquirir un disco SSD modelo OCZ Core Series V2 SATA II 2.5" SSD con 120 Gb, las comparativas con los últimos modelos presentados por Intel X25, decían que incluso iban por delante en cuanto a rendimiento, su coste bastante inferior, de unos 340 € frente a los 650 € de un Intel.

La primera impresión cuando lo tienes en las manos es lo poco que pesa, parece un trozo de plástico. Después de clonar el equipo e instalar el disco duro, el rendimiento no parece mejorar, es mas en algunas operaciones incluso parece más lento, consultando en los foros del fabricante, leo que hay que hacer varios ajustes relativos al cache, el servicio de indexado, desfragmentación y otros. Para los interesados dejo los ajustes aquí http://www.ocztechnologyforum.com/forum/showthread.php?t=47212, que supongo haya que realizar en todos los discos SSD. Me pregunto si algunos serán correctos, no lo tengo muy claro.

Lo curioso es que después de hacerlo las búsquedas de archivos son espectaculares, sin embargo el rendimiento general aparentemente sigue siendo muy bajo, los tiempos de compilación con Visual Studio son similares a la utilización de un disco SATA de 7200 rpm, incluso en algunos casos más altos, los test de disco me decían que el rendimiento en lecturas secuenciales era espectacular, en cambio en lecturas aleatorias dejaba mucho que desear, la gran ventaja de la utilización de este disco es que la batería del portátil a pasado a durar más del doble, de dos horas a casi 5, sigo haciendo cambios en la configuración a través de regedit, pues el fabricante ni siquiera ofrece un programa de configuración, el disco tiene una conexión USB para actualizar el firmware, pero este brilla por su ausencia, lo curioso es que antes de comprarlo estuve leyendo en varios post, que los resultados obtenidos con este tipo de discos pasaban por un aumento de rendimiento en torno a un 30 % frente a un disco SATA Normal, en resumen toda una decepción, espero que con alguna actualización y soporte de Windows 7 para discos SSD el rendimiento pueda mejorar, pero no lo tengo nada claro.

Quizás, para trabajar con herramientas de diseño grafico como autocad que maneja archivos grandes el rendimiento mejore, pero en mi caso con Visual Studio me temo que con la cantidad de archivos que tiene la solución y el tamaño de estos que normalmente no supera 20 Kb no sea así. Lo cierto es que estoy bastante decepcionado con este disco, esperaba al menos cierta mejoria en el rendimiento tal y como se comentaba en los artículos.

Por otra parte acabo de renovar mi antiguo PC, un AMD con doble núcleo de los primeros que salieron al mercado, 4 Gb de Ram y un disco serial ata de 250 Gb, adquirí un equipo DELL Optiplex 960 con un procesador Intel Quad Core, 8 Gb de Ram, Vista 64 y un disco SSD de 64 Gb de la marca Samsung.

Como sabéis Visual Studio no permite realizar cambios en tiempo de ejecución cuando estas depurando en 64 bits, no entiendo porque ni despues del Sp1 han incoporado esta característica que es verdaderamente importante. Como trataba de potenciar el rendimiento decidi renunciar a esta opción.

Con esta configuración los resultados son espectaculares, se reduce el tiempo de compilación en un 70 %, el equipo abre outlook en decimas de segundo, realmente espectacular, el disco utilizado tiene la mitad de capacidad que el primero, pero en rendimiento nada que ver, impresionante, hay que tener en cuenta de que el procesador tambien hace su trabajo en el proceso de compilación los cuatro procesadores no bajan del 60 % de rendimiento, el sistema operativo es de 64 bits, el uso de memoria no sobrepasa los 4 gygas. Resharper y Devexpress van como un tiro. Es increíble que en un equipo que ronda los 1200 €, el rendimiento haya mejorado tanto, la verdad merece la pena la inversión.

Aprovechando este post, he realizado otra prueba utilizando una tarjeta de memoria de 4 Gb, similar a esta http://www.gigabyte.com.tw/Products/Storage/Products_Overview.aspx?ProductID=2180 Desconozco la marca de la tarjeta que tengo ya que la consiguió un compañero a través de unos proveedores directamente en china, la de la foto es de la marca Gygabyte y es practicamente identica a la mia exceptuando la bateria que es una pila normal recargable de 1,5 V, En España todavía no he visto ningún sitio donde se comercializa.

Esta tarjeta te crea un disco virtual de memoria, esta sustentanda por una pequeña batería de litio que se recarga a través del slot PCI, para evitar perder los datos cuando apagamos el equipo, aquí también los resultados son espectaculares, después de dejar el proyecto en el disco de memoria que tiene una capacidad de 4 Gygas, suficiente para almacenar varios proyectos, y redirigir los archivos temporales a un directorio del propio disco, las pruebas son verdaderamente asombrosas, el rendimiento en la compilación es similar al logrado con el nuevo equipo con disco duro SSD. No os puedo poner el precio de esta tarjeta, pero según he leído es cara.

Otra posible solución de bajo coste para acelerar Visual Studio pasa por utilizar memorias Flash como las que se usan en las cámaras réflex digitales de alto rendimiento, abra que ver las especificaciones de lectura(escritura, esta es una de las mas rápidas actualmente..

Se pueden utilizar como un disco mas en un portatil o se pueden conectar a traves de un interface SATA como el de la foto a cualquier PC, no he realizado las pruebas con este tipo de dispositivos, una memoria de 4 Gb similar a la de la foto no costara mas de 70 €, la de la foto de 8 Gb esta sobre los 110 € y el un interface para pc sobre los 20 €.

El ahorro de costes que puede suponer trabajar con este tipo de dispositivos puede ser espectacular, imaginar un equipo de 8 personas que compilen una media de 10 veces al día y el proceso tome unos 4 minutos, supone que podemos ahorrarnos 4 horas diarias solo en la compilación, aunque el dispositivo solo mejorase un 30 % el rendimiento, ya merece la pena realizar la inversión.

Otra solución muy interesante y gratuita para los que dispongais de suficiente memoria, al menos 3 Gygas, puede ser la utilización de este programa gratuito, https://www.cenatek.com llamado RamDiskVe, el programa crea un disco virtual utilizando la memoria ram del equipo, las pruebas que he realizado han logrado mejorar el proceso mas de un 30 %, aunque el rendimiento al guardar el contenido del todo el disco antes de apagar el equipo no es muy bueno y tiene algun problema, de hecho la versión para Windows Vista es beta, pero puede ser una buena alternativa que no nos cuesta nada probar.

En resumen, cuidado al comprar un disco SSD, no todos son iguales… los discos de memoria pueden ser una buena alternativa y si teneís memoria suficiente probar RamDiskVe.

Os dejo un video sobre el samsung SSD, tarda un poco, pero merece la pena. http://www.youtube.com/watch?v=pJMGAdpCLVg

[View:http://www.youtube.com/watch?v=pJMGAdpCLVg:540:0]

Espero que el post os resulte útil.

Calidad de código

La calidad de software engloba muchos y diferentes aspectos sobre el desarrollo de aplicaciones, que pasan desde la elección de una buena arquitectura, hasta utilización de diferentes herramientas, la aplicación de diferentes técnicas y metodologías de trabajo. Creo que todavía hoy en día, existe mucha gente reticente a apostar por la calidad de código, debido a que piensan que su coste es mayor que su beneficio.

Cuando empecé a trabajar en equipo, surgieron una serie de problemas de difícil solución, en seguida me di cuenta de que los programadores escribimos código de forma muy diferente que realiza las mismas cosas, generalmente algunos, los más experimentados solían redactar un código mas legible, mejor documentado, necesitaban menos líneas para llegar a la misma solución, ya que sus conocimientos eran mayores, esto originaba muchos problemas cuando tenian que modificar o entender el código de los demás y es aquí cuando empecé a interesarme por las reglas de estilo, fxcop y otras herramientas que de alguna forma nos permitían establecer reglas para que todos pudiéramos por decirlo del alguna forma “entendernos mejor”. Por otra parte en la depuración de las aplicaciones observe que era mucho menos costoso detectar y corregir un error en una fase temprana que hacerlo posteriormente.

Para poder entender mejor el trabajo de los otros programadores comenzamos a aplicar algunas de estas reglas, desde normas de estilo, documentación, desarrollo de pruebas unitarias, aplicación de patrones de diseño, normativas de base de datos y un largo etc. Esto empezó a facilitarnos la compresión y la modificación de programas, en poco tiempo empezamos a tener una visión muy diferente del proyecto, nos aporto más claridad y conocimiento del trabajo de los demás y nos ayudo a detectar gran parte de errores en una fase temprana del desarrollo.

Algunos de los beneficios más importantes que observo son los siguientes:

- La aplicación de patrones de diseño suponen la solución más adecuada para resolver un problema determinado. Esta ha sido elaborada y seleccionada en base al entendimiento y posibles soluciones propuestas y analizadas por mucha gente.

- La adopción de herramientas como fxcop, stylecop, resharper, coderush, refactor y otras, permiten minimizar algunos errores en la fase de desarrollo además de obligar a cumplir ciertas reglas de calidad y estilo, que de no utilizar, provocan si el desarrollador no es un experto, a cometer errores de difícil detección como fugas de memoria, aprovechamiento óptimo de los recursos, localización de código no utilizado, y un largo etc. Por otra parte si todos las adoptan nos habituamos a escribir código de una manera similar, con lo que nos será más fácil comprender el trabajo de los demás. De la información de los errores que nos proporcionan aprendemos a programar mejor, liberando y utilizando recursos adecuadamente, con lo que nuestro conocimiento aumenta. Algunas de estas herramientas cuentan con utilidades para ayudarnos a escribir el código y refactorizar de una forma mucho más rápida.

- El uso de profiles nos permite detectar cuellos de botella y otros problemas que de otra forma serian prácticamente imposible de conocer.

- La utilización de pruebas unitarias y otras técnicas de testeo, nos permiten detectar errores en una fase temprana, si no lo hacemos a tiempo a veces puede implicar que tengamos que modificar más de un módulo relacionado con este, con lo que el coste se incrementa aún más. Como dice la frase, “más vale prevenir que curar”.La ventaja de contar con pruebas unitarias de un módulo que no hemos desarrollado nosotros nos permite entender mejor el comportamiento del programa. La aplicación es más fácil de modificar ya que si alguien altera el programa, por ejemplo cambiando el nombre de un campo de un procedimiento almacenado o alterando alguna función como el cálculo de totales de una factura, detectaríamos el error mucho antes de ponerlo en producción evitando mayores consecuencias.

- Se disminuye la dependencia del equipo de desarrollo: Si el día mañana alguno de los desarrolladores no está o la empresa de desarrollo cierra, será mucho más fácil encontrar a alguien que entienda el código que cumple unas determinadas reglas. Si cada miembro del equipo escribe software de forma diferente esto se hace practicamente imposible. Si otra persona o empresa externa cumple nuestros requisitos de calidad esto permite que pueda comprender y extender la aplicación más fácilmente.

La calidad de código no es opcional, de no aplicarla el coste de nuestros proyectos con seguridad será mayor.

Pero no todo es de color de rosa, utilizar estas herramientas requiere tiempo, formación y sobre todo constancia. Realizar pruebas unitarias además de ser costoso requiere mucha disciplina y un alto nivel de desarrollo, no solamente debemos preocuparnos de tener la máxima cobertura en nuestro código, si no que debemos intentar probar todos los extremos, valores nulos y otros factores que de no realizarse disminuyen los beneficios de estas. De igual forma aprender a utilizar profiles y otras herramientas llevan mucho tiempo en formación y desde luego tienen su coste. Tampoco debemos obsersionarnos, no creo que debamos realizar pruebas unitarias y cumplir con el 85 % de cobertura en todo nuestro proyecto o cumplir a raja tabla todas las reglas que propone fxcop, resharper, coderush, utilizar reglas de estilo, realizar pruebas de carga, utilizar mock objects para crear independencia con nuestro entorno de datos, utilizar profiles para analizar hasta la más mínima señal de que algo va mal, etc, debemos comenzar poco a poco implantando alguna y habituarnos a utilizarla. Si haceís esto e invertimos un poco de tiempo en aprender a sacarles partido, os puedo asegurar que la mayoría se harán indispensables en vuestro trabajo.

Recuerdo que la primera vez que pusimos en marcha fxcopy en uno de los proyectos aparecieron miles de warnings, os aseguro que fue un autentico coñazo eliminarlos, ya que lo aplicamos en una fase media del desarrollo, nos costó bastante tiempo poner la aplicación en orden, pero aprendimos un motón de cosas sobre programación, algunas que nunca hubiéramos conocido si no llega a ser por este tipo de herramientas. Ahora no podemos vivir sin él y cuando vemos una aplicación que no lo utiliza en seguida nos damos cuenta de los errores que se cometen. Tampoco debemos obsesionarnos con la calidad, nunca seremos capaces de desarrollar el sistema perfecto, los cambios casi diarios en la tecnología hacen que esto sea prácticamente imposible, cada vez aparecen más técnicas y actualizaciones que hacen que obsesionarse por la calidad al igual que con la seguridad solo nos llevara a caer en un abismo sin fin.

Las ventajas de desarrollar código de calidad son innumerables, se facilitan la detección precoz de errores y nos permiten anticiparnos y corregirlos antes de poner el sistema en producción evitando tener que rehacer gran parte de las aplicaciones. Estas herramientas nacen con el objetivo de permitirnos mejorar en nuestros desarrollos, no quiere decir que nuestra aplicación vaya a estar libre de fallos, pero si que será mejor, que aprovechara mejor los recursos y por supuesto, que tendrá menos errores, tendremos mayor seguridad a la hora de modificar un programa y reglas de trabajo en equipo que de otra forma serian muy difíciles de controla, se facilita la escritura de código y la detección visual de errores en tiempo de diseño, ahorrando mucho tiempo a la hora de programar y depurar la aplicación.

El esfuerzo que debemos realizar para desarrollar código de calidad es grande, pero marcara la diferencia y en poco tiempo nos permitirá recuperar la inversión con creces, así que animaros, merecerá la pena.

Calidad de código

La calidad de software engloba muchos y diferentes aspectos sobre el desarrollo de aplicaciones, que pasan desde el estudio de la arquitectura, hasta utilización de diferentes herramientas, la aplicación de diferentes técnicas y metodologías de trabajo. Creo que todavía hoy en día, existe mucha gente reticente a apostar por la calidad de código, debido a que piensan que el coste que tiene es mayor que su beneficio.

Cuando empecé a trabajar en equipo, surgieron una serie de problemas de difícil solución, en seguida me di cuenta de que los programadores escribimos código de forma muy diferente que realiza las mismas cosas, generalmente algunos, los más experimentados solían escribir un código mas legible, mejor documentado, necesitaban menos líneas para llegar a la misma solución, ya que sus conocimientos eran mayores, esto originaba muchos problemas cuando tenias que modificar o entender el código de los demás y es aquí cuando empecé a interesarme por las reglas de estilo, fxcop y otras herramientas que de alguna forma nos permitían establecer reglas para que todos los integrantes de un equipo pudiéramos “entendernos”. Cuando oí hablar de calidad de software me asuste bastante, lo relacionaba directamente con calidad = burocracia, “creo que fue debido a mi trabajo con la norma ISO 9001”, en seguida me di cuenta de que era mucho menos costoso detectar y corregir un error en una fase temprana que hacerlo posteriormente.

Para poder llegar a entender el trabajo de los otros programadores se hizo necesario establecer ciertas reglas que fueron utilizadas por todo el equipo de desarrollo, desde reglas de estilo, documentación, desarrollo de pruebas unitarias, aplicación de patrones de diseño, reglas de base de datos y un largo etc. de normas. Esto empezó a facilitarnos la compresión y la modificación de programas por otros miembros del equipo. Muchas de estas técnicas aplicadas en conjunto comenzaron en poco tiempo a darnos una visión muy diferente del proyecto, nos aporto más claridad y conocimiento del trabajo de los demás y nos ayudo a detectar una gran parte de errores en una fase temprana del desarrollo.

Algunos de los beneficios más importantes de la utilización de estas técnicas son las siguientes:

- La aplicación de patrones de diseño suponen la solución más adecuada para resolver un problema determinado. Esta ha sido elaborada en base al entendimiento y posibles soluciones del problema.

- La adopción de herramientas como fxcop, stylecop, resharper, coderush, refactor y otras, permiten minimizar algunos errores en la fase de desarrollo además de obligar a cumplir ciertas reglas de calidad y estilo que de no utilizar provocan si el desarrollador no es un experto a cometer errores de difícil detección como fugas de memoria, aprovechamiento óptimo de los recursos, localización de código no utilizado, y un largo etc. Por otra parte si todo el equipo utiliza estas herramientas nos habituamos a escribir código de una manera similar, con lo que nos será más fácil comprender el trabajo de los demás. De la información de los errores que nos proporcionan estas herramientas aprendemos a programar mejor, a liberar recursos y utilizarlos adecuadamente, con lo que nuestro conocimiento aumenta. Algunas de estas herramientas cuentan con utilidades para ayudarnos a escribir el código y refactorizar de una forma mucho más rápida.

- El uso de profiles nos permite detectar cuellos de botella y otros problemas que de otra forma serian prácticamente imposible de conocer.

- La utilización de pruebas unitarias y otras técnicas de testeo, nos permiten detectar errores en una fase temprana, si no detectamos estos a tiempo a veces puede implicar que tengamos que modificar más de un módulo relacionado con este, con lo que el coste se incrementa aún más. Como dice la frase, “más vale prevenir que curar”.

La ventaja de tener pruebas unitarias de un módulo que no hemos desarrollado nosotros nos permite entender mejor el comportamiento del programa.

La aplicación es más fácil de modificar ya que si alguien altera el programa, por ejemplo cambiando el nombre de un campo de un procedimiento almacenado o alterando alguna función como el cálculo de totales de una factura, detectaríamos el error mucho antes de ponerlo en producción y evitando mayores consecuencias.

- La calidad de código disminuye la dependencia del equipo de desarrollo: Si el día mañana alguno de los desarrolladores no está o la empresa de desarrollo cierra, será mucho más fácil encontrar a alguien que entienda el código que cumple unas determinadas reglas. Si otra persona o una empresa externa cumple nuestros requisitos de calidad esto permite que pueda comprender y extender la aplicación más fácilmente.

La calidad de código no es opcional, de no aplicarla el coste de nuestros proyectos con seguridad será mayor.

Pero no todo es de color de rosa, utilizar estas herramientas es complejo y difícil, por ejemplo, realizar pruebas unitarias además de ser costoso requiere mucha disciplina y un alto nivel, no solamente debemos preocuparnos de tener una cobertura de nuestro código, si no que debemos intentar probar todos los extremos, valores nulos y otros factores que de no realizarse bien disminuyen los beneficios de estas. De igual forma aprender a utilizar profiles y otras herramientas conllevan mucho tiempo en formación y desde luego tiene su coste.

No quiero decir que debamos hacer pruebas unitarias y cumplir con el 85 % de cobertura en todo nuestro proyecto o cumplir a raja tabla todas las reglas que propone fxcop, resharper, coderush, utilizar reglas de estilo, realizar pruebas de carga, utilizar mock objects para crear independencia con nuestro entorno de datos, utilizar profiles para analizar hasta la más mínima señal de que algo va mal, etc, Esto sería lo ideal, pero si nos habituamos a utilizarlas e invertimos un poco de tiempo en aprender a sacarles partido, os puedo asegurar que la mayoría de ellas se harán indispensables en vuestro trabajo.

Recuerdo que la primera vez que pusimos en marcha fxcopy en uno de los proyectos aparecieron miles de errores, os aseguro que fue un autentico coñazo eliminarlos, ya que lo aplicamos en una fase media del desarrollo, nos costó bastante tiempo poner la aplicación en orden, pero aprendimos un motón de cosas sobre programación, algunas que nunca hubiéramos conocido si no llega a ser por este tipo de herramientas. Ahora no podemos vivir sin él y cuando vemos una aplicación que no lo utiliza en seguida nos damos cuenta de los errores que se cometen.

No debemos obsesionarnos con la calidad, nunca seremos capaces de desarrollar el sistema perfecto, los cambios casi diarios en la tecnología hacen que esto sea prácticamente imposible, cada vez aparecen más técnicas y actualizaciones que hacen que obsesionarse por la calidad al igual que con la seguridad solo nos llevara a caer en un abismo sin fin.

Las ventajas que nos ofrecen todas estas técnicas en conjunto nos facilitan la detección precoz de errores y nos permiten anticiparnos y corregirlos antes de poner el sistema en producción evitando tener que rehacer gran parte de las aplicaciones.

Estas técnicas y utilidades nacen con el objetivo de permitirnos mejorar en nuestros desarrollos, no quiere decir que nuestra aplicación vaya a estar libre de errores. Pero si que será mejor, que aprovechara mejor los recursos y por supuesto, que tendrá menos errores. Nos ofrecen mayor seguridad a la hora de tener que modificar un determinado programa y permiten trabajar con ciertas reglas de trabajo en equipo que de otra forma serian muy difícil de establecer y controlar. Algunas nos facilitan la escritura de código y la detección visual de errores en tiempo de escritura, ahorrando mucho tiempo a la hora de depurar la aplicación.

El esfuerzo que debemos realizar para trabajar con calidad de código es muy grande, pero marcara la diferencia y en poco tiempo nos permitirá recuperar la inversión con creces, así que animaros, el esfuerzo merecerá la pena.