Es bastante conocida la conveniencia de tener una tabla numérica como apoyo a determinadas operaciones. Sin embargo, sobre todo cuando trabajamos con fechas, es necesario extender esta tabla y aclarar el rango que necesitamos. Veamos por qué.
PRIMER EJEMPLO
Cuando usamos la tabla de números para procesar un rango de fechas, lo normal es que queramos empezar en el primer día inclusive. Como dichas tablas en la literatura generalmente empiezan con el 1, nos toca emplear un código complejo que además tenemos que comentar. Por ejemplo, si tenemos unos contratos con día inicio, día fin y un campo que refleja los días que trabaja durante la semana, con una tabla de números «normal» tendríamos:
Donde vemos que en esta base de datos se guardan los días que se trabaja en un campo de texto en el que el lunes es el día cero y el domingo el seis y que aquí hemos representado con una variable para simplicidad –@DiasSemanas–. Dada la configuración de dicho campo, hay construida además una tabla auxiliar –ADM_DiasTrabaja– para tratar cualquier consulta relacionada con esta forma de guardar los días de la semana para los que está contratado el personal:
Vemos que hay una correspondencia con la configuración del servidor SQL Server donde el primer día de la semana es el lunes con identificador 1, y el formato heredado donde dicho día es 0T –si trabaja o 0F si no–. Bueno, la pregunta que resuelve la función donde está este código es cuántos días va a trabajar entre dos fechas y esta tabla auxiliar nos permite emplear una consulta SQL en vez de un cursor. SQL en estado puro.
La importancia del rango
Además, no necesariamente va a existir el número cero desde el principio, porque si la tabla numérica la hemos creado según la literatura «normal», dicha tabla va a empezar en el uno y vamos a usar consultas que asumen que ese es el inicio. Como eso realmente es mucho asumir, especialmente si nuestras consultas van a ser mantenidas posteriormente por otra persona, lo mejor es dejar bien claro qué es lo que queremos. Por esto, para mejorar la depuración posterior, es importante usar un rango en vez de consultas que impiden modificar la tabla de números.
En definitiva, nuestra consulta anterior, usando una tabla que contenga el cero, sería mucho más explicativa, porque vemos claramente que el primer día es inclusive y que el rango va del primer día al último:
Otros ejemplos
Si necesitamos el primer día del mes en un rango de meses, una vez calculado el primero, es muy fácil hacerlo con una tabla de números. En este caso vemos que, sí se usa el rango, por lo que estamos protegidos de posibles cambios en la tabla, pero la tabla empieza en 1, por lo que hay que tenerlo en cuenta en la consulta y poner una nota:
En esta consulta observamos una forma de sortear el hecho de que no haya cero en la tabla: necesitamos los meses desde el actual hasta el año que viene más uno –trece meses– para lo que usamos directamente N – 1 en todas partes:
Por último, en otra consulta vemos que si usamos rangos, no tienen por qué empezar por cero o uno, pueden ser cualquier número, lo que incrementa la flexibilidad:
NÚMEROS NEGATIVOS
Nos puede surgir la duda: ¿debería tener dígitos negativos una tabla de números? Pues si usamos rangos no afectaría al resultado de las consultas. La velocidad va a ser muy parecida porque esta tabla suele ser pequeña. Yo nunca he visto que se necesitasen, pero si hay algún diseño de consulta que los use, pues se añaden.
En realidad tiene la misma respuesta que otra pregunta sobre este tipo de tabla, ¿cuántas filas hay que crear?: las que se necesiten.
CONCLUSIÓN
En muchos sitios se explica la conveniencia y los usos de una tabla de números. En este artículo hemos incidido en la conveniencia de que tenga cero, especialmente para trabajar con fechas, y en el uso de rangos. Ambas ideas hacen que nuestras consultas sean más fáciles de leer –y por lo tanto de depurar– y le añaden más flexibilidad.
Dejar un comentario
¿Quieres unirte a la conversación?¡Siéntete libre de contribuir!