Cuando la cantidad de valores distintos que podemos tener en una columna es fija y es pequeña podemos usar dominios, pero si la cantidad crece entonces es más conveniente usar tablas de validación.

Ejemplo 1:

En una columna queremos guardar el sexo de una persona, sus valores posibles son ‘F’ y ‘M’ (femenino y masculino, respectivamente) entonces tener un dominio resuelve nuestro problema.

Ejemplo 2:

En una columna queremos guardar el estado civil de una persona, sus valores posibles son: ‘S’, ‘C’, ‘P’, ‘D’, ‘V’ (soltero, casado, separado, divorciado, viudo, respectivamente). También en este caso un dominio resuelve nuestro problema.

Ejemplo 3:

En una columna queremos tener la abreviatura del estado de los Estados Unidos, pero hay 50 estados y por lo tanto 50 abreviaturas (AL=Alabama, AK=Alaska, AZ=Arizona, AR=Arkansas, etc.) y eso ya es demasiado para un dominio, claro que podríamos usar un dominio también pero para estos casos es mejor usar una tabla de validación.

TABLAS1

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

TABLAS2

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

Para asegurarnos de no tener valores duplicados, la columna EST_ABREVI debería tener una restricción Unique Key y la columna EST_NOMBRE también debería tener una restricción Unique Key.

Supongamos que deseamos registrar a cual de esos estados pertenece nuestro proveedor. Entonces, en un trigger “Before Insert or Update” de la tabla PROVEEDORES escribiríamos:

CREATE TRIGGER PROVEEDORES_BIU FOR PROVEEDORES
ACTIVE BEFORE INSERT OR UPDATE
POSITION 1
AS
BEGIN
   IF (NEW.PRO_ESTUSA NOT IN (SELECT EST_ABREVI FROM ESTADOS_USA)) THEN
      EXCEPTION E_ESTADO_USA_INEXISTENTE;
END;

O sea que si se quiere insertar o actualizar en la columna PRO_ESTUSA (Estado de los Estados Unidos donde se encuentra el Proveedor) un valor que no se encuentre en la columna EST_ABREVI de la tabla ESTADOS_USA se lanzará la excepción de que ese Estado no existe.

De esta manera nos aseguramos de que siempre en la columna PRO_ESTUSA tengamos un valor correcto.

Otra forma de conseguir este mismo efecto es con una Foreign Key que relacione a las columnas PRO_ESTUSA y EST_ABREVI. Sólo que si son muchos proveedores podría no justificarse porque la Foreign Key creará un índice que debe ser mantenido, consumiendo tiempo quizás innecesariamente.

Hay muchos otros casos en los cuales usar tablas de validación es muy útil, por ejemplo:

  • Nombres de todos los documentos contables y administrativos
  • Nombres de todos los Bancos del país
  • Nombres de todos los impuestos
  • Nombres de todos los municipios
  • Nombres de todas las sucursales
  • Nombres de todos los países
  • Nombres de todas las monedas extranjeras utilizadas
  • etc.

Una de las ventajas de usar tablas de validación y no dominios es que se puede crear fácilmente un programa que le permita al usuario final agregar más filas. Por ejemplo, si un nuevo Banco empieza a operar en el país el usuario podría agregar el nombre de ese Banco a la tabla de BANCOS. Si usáramos un dominio entonces el Administrador de la Base de Datos tendría que agregar el nombre del Banco al dominio adecuado y siempre es preferible que los metadatos se toquen lo menos posible en una Base de Datos que está en producción.

Conclusión:

Si la cantidad de valores distintos que podemos tener en una columna es fija y es pequeña entonces podemos usar dominios, pero si la cantidad crece es más conveniente usar tablas de validación. En este caso, con un trigger “Before Insert or Update” nos aseguramos de que el valor que se quiere escribir en una columna sea un valor admitido. Además, si usamos tablas de validación le podemos agregar a nuestras aplicaciones la opción de que sean los usuarios quienes agreguen filas a esas tablas.

Artículo relacionado:

El índice del blog Firebird21

 

Anuncios