Siempre debemos verificar que en nuestras tablas tengamos valores correctos y solamente valores correctos porque cualquier valor incorrecto es basura y la basura jamás puede ser buena.

Si una columna tiene una restricción Foreign Key entonces si la tabla padre tiene valores correctos podemos estar seguros que la tabla hija también los tendrá. Pero … ¿y si la columna no tiene una restricción Foreign Key?

Supongamos que tenemos una columna para conocer el sexo de una persona, ‘F’=femenino, ‘M’=masculino. ¿Cómo podríamos verificar que tengamos solamente esos valores y que no tengamos ‘m’, ‘f’, ‘1’, ‘0’, o cualquier otra cosa?

SELECT
   *
FROM
   MiTabla
WHERE
   MiColumna NOT IN ('F', 'M')

En nuestra tabla cabecera de movimientos tenemos una columna llamada MVC_TIPMOV que nos indica cual es el tipo de movimiento. ‘ECM’ = entrada por compras, ‘SVT’ = salida por ventas, ‘EDV’ = entrada por devolución, ‘SDV’ = salida por devolución, ‘COB’ = cobranza, ‘PAG’ = pago. ¿Cómo podemos estar seguros que la columna MVC_TIPMOV tenga solamente uno de esos valores?

SELECT
   *
FROM
   MOVIMCAB
WHERE
   MVC_TIPMOV NOT IN ('ECM', 'SVT', 'EDV', 'SDV', 'COB', 'PAG')

¿Y para saber si algún movimiento ocurrió en un año distinto a 2011, 2012, 2013, que son los únicos años permitidos?

SELECT
   *
FROM
   MOVIMCAB
WHERE
   EXTRACT(YEAR FROM MVC_FECHAX) NOT IN (2011, 2012, 2013)

Conclusión:

Siempre debemos verificar que en nuestras tablas tengamos valores correctos y solamente valores correctos porque los valores incorrectos jamás servirán para algo bueno. Podemos hacer esa verificación con NOT IN.

Inclusive sería muy bueno que en nuestros programas agreguemos una opción que le permita a los usuarios realizar esta verificación. Si la verificación finaliza sin errores entonces podemos asegurarle que no tiene basura en sus tablas. Y si al verificar se encuentran errores entonces por supuesto que se debe corregirlos inmediatamente.

Artículo relacionado:

El índice del blog Firebird21