Para evitar que ingrese basura en nuestra tabla (se le llama basura a un dato que está pero que no debería estar) el Firebird nos provee de varias armas: dominios, triggers y checks.

Un check es una restricción, una limitación que deben cumplir los datos para que sean considerados válidos y puedan ser grabados.

Por ejemplo, si los precios no pueden ser negativos podríamos tener un check que evite guardar precios negativos. Si las notas de los alumnos deben estar entre 0 y 100 podemos tener un check que evite ingresar notas fuera de ese rango. Si las fechas no pueden ser anteriores al día 1 de enero de 2013 podemos tener un check que evite ingresar fechas anteriores.

Todos esos ejemplos involucran a una sola tabla cada vez, pero el Firebird también nos permite tener checks que involucren a varias tablas. Los usaríamos por ejemplo para evitar que la cobranza se realice antes de la venta, o que el examen se realice antes de la inscripción del alumno, o que el cheque sea emitido antes de la apertura de la cuenta corriente en el Banco.

Después de haber creado una tabla le podemos agregar todos los checks que necesitemos. La sintaxis es la siguiente:

ALTER TABLE MiTabla ADD CONSTRAINT NombreCheck CHECK (MiCondición);

En EMS SQL Manager para escribir un check debes hacer click sobre la pestaña respectiva, como se muestra en esta imagen:

CHECK1

(haciendo click en la imagen la verás más grande)

Ejemplo 1. Evitar precios de costo negativos

ALTER TABLE
   PRODUCTOS
ADD CONSTRAINT
   CHK_PRODUCTOS1
CHECK (PRD_PRECTO >= 0);

La tabla se llama PRODUCTOS y en la columna PRD_PRECTO se guardan los precios de costo de los productos

Ejemplo 2. Evitar que las notas de los alumnos estén fuera de rango

ALTER TABLE
   EXAMENES
ADD CONSTRAINT
   CHK_EXAMENES1
CHECK(EXA_NOTAXX >= 0 AND EXA_NOTAXX <= 100);

La tabla se llama EXAMENES y en la columna EXA_NOTAXX se guardan las notas de los alumnos

Ejemplo 3. Evitar que la fecha de la venta sea anterior al 1 de enero de 2013

ALTER TABLE
   VENTASCAB
ADD CONSTRAINT
   CHK_VENTASCAB1
CHECK (VTC_FECHAX >= '01-01-2013');

La tabla se llama VENTASCAB (cabecera de las ventas) y en la columna VTC_FECHAX se guardan las fechas de las ventas

Ejemplo 4. Evitar la grabación si el valor de una columna no existe en otra tabla

ALTER TABLE
   BANCOS
ADD CONSTRAINT
   CHK_BANCOS1
CHECK (BAN_CODSUC IN (SELECT SUC_CODIGO FROM SUCURSALES));

La tabla se llama BANCOS y en la columna BAN_CODSUC se guarda el código de la Sucursal. Se busca ese código en la tabla de SUCURSALES. Si no existe, entonces esta fila no podrá ser grabada. Esta no es la única forma de resolver este problema, pero se muestra aquí para que puedas ver como usarla cuando necesites que una fila se grabe solamente si existe un valor (o más de un valor) en otra tabla.

Conclusión:

La restricción CHECK es extremadamente útil para evitar que alguien ingrese basura en las tablas de nuestra Base de Datos. Si la usamos bien entonces no estaremos dependiendo de que los programas (escritos en Visual FoxPro, Visual Basic, C, C++, Delphi, Java, PHP, etc.) se acuerden de evitar el ingreso de la basura. Simplemente si un dato no cumple con la restricción del check no será grabado. Punto.

En los ejemplos de arriba se mostró como evitar algunas situaciones comunes pero desde luego que hay muchísimas otras posibilidades. Como el Firebird nos permite tener un SELECT (o más de un SELECT) dentro de un CHECK entonces la cantidad de condiciones que podemos escribir es impresionante, y deberíamos usar esta facilidad para que nuestra Base de Datos sea confiable.