En Firebird todos los datos que los usuarios quieren guardar se guardan (archivan o almacenan o registran, son sinónimos) en las tablas que el programador diseñó.

Es por lo tanto importante que esas tablas estén bien diseñadas ya que si no lo están varios problemas podrían ocurrir, entre ellos:

  • Desperdicio de espacio en disco
  • Consultas lentas
  • Datos incorrectos o inconsistentes

El diseño correcto de las tablas se logra mediante la normalización, y ese no es el objeto de este artículo ya que mucho se ha escrito sobre normalización y en Internet encontrarás un montón de documentación al respecto, así que asumiré que entiendes esos conceptos. Este artículo es más bien sobre el diseño de tablas con Firebird.

En una Base de Datos relacional, como las son todas las de Firebird, los datos que los usuarios almacenan se guardan en tablas. Estas tablas constan de filas y columnas. Las columnas son diseñadas por el programador y el usuario es el encargado de guardar datos en ellas.

Todas las tablas deberían tener una Primary Key, la única excepción serían las tablas que tienen solamente una fila (que se usa por ejemplo para guardar los parámetros de configuración de la aplicación).

Esa Primary Key sirve para dos objetivos:

  1. Para identificar a cada fila sin posibilidad de equivocación
  2. Para relacionar a esta tabla con otras tablas

Además, si los datos de esta tabla dependen de los datos de otra tabla, debería existir una Foreign Key que las relacione. Por ejemplo, la venta de un producto debe estar relacionada con la tabla de Productos. No podemos vender un kilo de manzanas si en la tabla de Productos no existe al menos una fila donde se guardan los datos de las manzanas. No podemos calificar a un alumno si en la tabla de Inscripciones no se encuentra la inscripción de ese alumno.

Cuando se definen las columnas de una tabla se pueden usar tipos de columnas estándar o dominios. Lo correcto es que siempre se usen dominios porque le dan al programador mucho más control sobre los datos que pueden guardarse en esa columna.

Las columnas por las cuales frecuentemente se hacen búsquedas o consultas deberían estar indexadas porque eso aumenta muchísimo la velocidad.

Pero si una columna tiene muchos valores repetidos no debería ser indexada porque eso hará que las consultas y las búsquedas sean lentísimas. Por ejemplo tener un índice según la columna sexo del alumno sería un gran error, porque esa columna solamente puede tener dos valores posibles (femenino o masculino).

Nunca debería permitirse que entre basura en una tabla. Se llama basura a cualquier  dato que está en la tabla pero que no debería estar allí. Para evitar que entre basura se usan los triggers. Ejemplos de basura pueden ser: el precio de venta es negativo, la fecha de la cobranza es anterior a la fecha de la venta, se vendió un producto inexistente, se registró la venta de un producto pero no se sabe en que fecha fue la venta ni a quien se le vendió.

Resumiendo:

  • Las tablas deben estar normalizadas
  • Todas las tablas deben tener una Primary Key (salvo que nunca puedan tener más de una fila)
  • Si los datos de una tabla dependen de los datos de otra tabla, ambas tablas deben estar relacionadas mediante una Foreign Key
  • Los índices aumentan mucho la velocidad de consulta y de búsqueda cuando son creados según las columnas correctas
  • Crear un índice según una columna que tiene muchos valores repetidos es un gran error
  • Es muchísimo más preferible usar dominios que tipos de datos estándar para definir a las columnas de una tabla porque los dominios le dan mucho mayor control al programador
  • Nunca debe permitirse que entre basura en una tabla y para evitar que entre basura se pueden usar los triggers

 

Anuncios