Usando scripts para documentar la Base de Datos

Deja un comentario

Si hay una verdad innegable en Informática es que a la grandísima mayoría de los programadores no nos gusta documentar. Sabemos muy bien que eso es lo correcto, que debemos hacerlo … pero no lo hacemos.

Aunque no nos salvaremos de escribir algo, los scripts de Firebird nos ayudarán a escribir poco y sin embargo tener muy bien documentada a nuestra Base de Datos.

La técnica es la siguiente:

  • Cuando creamos una Base de Datos generamos su script. En él escribimos la fecha en que fue creada y algún otro comentario relevante.
  • Cada vez que modificamos los metadatos generamos un script. En él escribimos la fecha de la modificación, cual/es metadato/s cambiamos y algún otro comentario relevante

Si hacemos esto tendremos algo buenísimo: el historial completo de nuestra Base de Datos, con todos los cambios que alguna vez fueron realizados en ella y las fechas de tales cambios.

Entonces si alguien ¿nosotros mismos? por intención o por ignorancia modificó algún metadato podremos regresarlo a su estado original, rápidamente y sin esfuerzo.

¿Cómo se genera un script?

En este artículo se explica como hacerlo:

https://firebird21.wordpress.com/2013/05/22/entendiendo-a-los-scripts/

Ejemplo:

Queremos documentar mediante scripts una Base de Datos que se llama INTEGRAL.FDB entonces cuando terminamos de trabajar con ella el primer día generamos un script, le llamamos INTEGRAL001.SQL y le escribimos la fecha:

SCRIPT01

Captura 1. Si haces clic en la imagen la verás más grande

A partir de ese día cada vez que modificamos los metadatos, cuando terminamos de trabajar con ellos generamos otro script donde indicamos que fue lo que le hicimos. Este se llama INTEGRAL002.SQL:

SCRIPT02

Captura 2. Si haces clic en la imagen la verás más grande

Fíjate que no es necesario especificar cuales fueron los cambios realizados sino solamente qué se cambió. Si queremos saber cuales fueron los cambios (por ejemplo en la tabla CLIENTES) podemos buscar esa tabla en el script y allí los veremos. Desde luego que si quieres escribir cuales fueron los cambios en la cabecera del script también puedes hacerlo aunque en general no es necesario.

Conclusión:

Mantener bien documentados los cambios que le realizamos a nuestra Base de Datos es importantísimo para poder en cualquier momento saber que fue lo que hicimos (o algún otro le hizo, sin nuestra autorización) y en caso necesario retrotraerla a su estado anterior.

Es cierto, documentarla lleva un poco de tiempo y no nos gusta documentar pero los beneficios que obtendremos con esta práctica el día que ocurra algún problema serán inmensos y compensarán con creces el tiempo que empleamos en documentar la Base de Datos.

Es una buena idea que cuando instalas la Base de Datos en la computadora de tu cliente o cuando modificas esa Base de Datos especifiques cual script le corresponde. Por ejemplo: el cliente 1 tiene instalada la Base de Datos que corresponde al script 017, el cliente 2 tiene instalada la Base de Datos que corresponde al script 023, etc.

Artículos relacionados:

Entendiendo a los scripts

El índice del blog Firebird21

INNER JOIN y OUTER JOIN

20 comentarios

En la literatura SQL frecuentemente encontrarás estos términos: INNER JOIN y OUTER JOIN.

¿Qué significan y cuál es la diferencia entre ellos?

Un JOIN (juntar) es una relación entre dos tablas. Esas tablas pueden ser de cualquier tipo: tablas reales, vistas, tablas CTE, tablas GTT, etc. Si quieres (y puedes) relacionarlas entonces es posible usar un JOIN.

Un INNER JOIN (juntar internamente) requiere que para cada fila de la tabla A exista una fila en la tabla B. Por eso se dice que es “interno” porque es un requisito que todas las filas puedan emparejarse.

Un OUTER JOIN (juntar externamente) no requiere que para cada fila de la tabla A exista una fila en la tabla B. Se dice que es “externo” porque en el resultado podrían mostrarse filas que no fueron emparejadas. Cuando dos filas no pueden emparejarse se coloca un NULL en las columnas donde no existen datos.

Recuerda que en SQL la palabra NULL significa “desconocido”.

¿Por qué usar un OUTER JOIN, cuál sería el beneficio?

Cuando usamos un INNER JOIN mostramos datos que actualmente existen en ambas tablas. En cambio cuando usamos un OUTER JOIN podemos mostrar datos que no existen en una de las tablas.

Por ejemplo, si relacionamos “internamente” la tabla ALUMNOS con la tabla EXÁMENES podemos mostrar los datos de todos los alumnos que fueron examinados, pero solamente de ellos, no podríamos saber cuales fueron los alumnos que por algún motivo no fueron examinados. En cambio si las relacionamos “externamente” podemos mostrar los datos de todos los alumnos, hayan sido examinados o no.

Si relacionamos “internamente” las tablas PRODUCTOS y VENTAS podemos mostrar los datos de todos los productos vendidos. Pero no podríamos saber cuales fueron los productos que no se vendieron. En cambio si relacionamos esas tablas “externamente” sí podríamos saber cuales productos no se vendieron.

Tipos de OUTER JOIN

Hay tres tipos de OUTER JOIN, dependiendo si los datos que sí o sí serán mostrados se encuentran en la primera tabla, en la segunda tabla, o en ambas tablas.

LEFT OUTER JOIN: Los datos de la tabla de la izquierda (LEFT) se muestran sí o sí. Los de la tabla de la derecha se muestran solamente si se los pudo emparejar, en caso contrario se muestra NULL.

RIGHT OUTER JOIN: Los datos de la tabla de la derecha (RIGHT) se muestran sí o sí. Los de la tabla de la izquierda se muestran solamente si se los pudo emparejar, en caso contrario se muestra NULL.

FULL OUTER JOIN: Se muestran todas las filas de cada tabla, poniendo NULL cuando no se puede emparejar.

Equivalencia entre INNER JOIN y OUTER JOIN

Hay casos en que se obtiene exactamente el mismo resultado si usamos un INNER JOIN o si usamos un OUTER JOIN. Eso se da cuando entre las dos tablas existe una restricción Foreign Key y nuestro OUTER JOIN es:

  • TablaPadre LEFT OUTER JOIN TablaHija
  • TablaHija RIGHT OUTER JOIN TablaPadre

O sea que en los tres casos siguientes obtendremos exactamente el mismo resultado:

La tabla VENTAS es la tabla hija, y la tabla PRODUCTOS es la tabla padre. Eso significa que todos los productos vendidos deben existir.

SELECT
   Columnas
FROM
   VENTAS V
INNER JOIN
   PRODUCTOS P
      ON MiCondición
SELECT
   Columnas
FROM
   PRODUCTOS P
LEFT OUTER JOIN
   VENTAS V
      ON MiCondición
WHERE
   V.Identificador IS NOT NULL
SELECT
   Columnas
FROM
   VENTAS V
RIGHT OUTER JOIN
   PRODUCTOS P
      ON MiCondición
WHERE
   V.Identificador IS NOT NULL

Al autor de este blog le parece más sencilla y más fácil de entender la primera de las tres alternativas, pero sobre gustos …

Precaución:

Algo muy IMPORTANTE a recordar es que los JOIN puedes usar para relacionar dos tablas cualesquiera aunque no exista una restricción Foreign Key entre ellas, pero tal cosa puede ser muy peligrosa porque en la mayoría de los casos obtendrías datos que no tienen sentido … aunque parecerán tenerlos. Esto no significa que no se puedan relacionar tablas que no tienen una restricción Foreign Key, claro que sí pueden relacionarse pero con mucho cuidado porque de lo contrario se mostrarán resultados inconsistentes.

En otras palabras, lo seguro es hacer el JOIN entre dos tablas que tienen una restricción Foreign Key entre ellas, si no tienen esa restricción, hmmmmmmmm.

Artículo relacionado:

El índice del blog Firebird21