Hola:
Aunque definas relaciones de Integridad Referencial (IR) o de Lookup a nivel de tabla, desde el Database Desktop por ejemplo, eso no te libra de tener que volver a enlazarlas de nuevo desde Delphi, por los procedimientos de crear una relación Maestro-Detalle o de definir un campo Lookup que ya sabrás.
El definirlo a nivel de base de datos, no de aplicación, le da más solidez puesto que centralizas las reglas, además el DDesktop te crea los índices necesarios en cada caso. Pero, como digo, cuando coloques en Delphi las dos tablas relacionadas vas a tener que indicarle a Delphi esa relación para que se comporten sus componentes de esa forma. Eso sí, deberás asegurarte de tener creados los índices pertinentes en cualquier caso.
Otra cosa bien diferente es que las reglas definidas a nivel de tabla generan unas restricciones que ahora no tendrás que definir a nivel de aplicación; me explico, si en Delphi tratas de asignar un valor a un campo ligado como LookUp a otra tabla, todo esto definido a nivel de Base de Datos, si ese valor no existe en la tabla de búsqueda, te saltará una Excepción, lo mismo si has definido una relación de Integridad, el mismo motor BDE impide que hagas ciertas operaciones que violen estas reglas. Desde Delphi no tienes que controlar esas situaciones sino esperar a que salte la excepción y tratarla.
¿Ventajas de definir estas reglas a nivel de BD?
- La que te he comentado de que es el motor quien controla ciertas restricciones, así te evitas un trabajo extra de control. Cuando el usuario ingresa un valor inválido, salta la excepción. Además, el centralizar todo en la BD es lo recomendado.
- Si en la Integridad Referencial defines comportamientos en Cascada, te ahorrarás más de una vez el tener que lanzar Querys que actualicen tablas dependientes, esto ya lo hará el BDE. Imagínate que tienes una factura con ID = 890, con sus 10 líneas de factura dependientes. Si en la tabla de cabecera cambias el ID de 890 a 1000, automáticamente se cambiará a 1000 la clave foránea en las lineas. Y en el caso de borrados en cascada también te ahorras un trabajo.
¿Inconvenientes?
- Si te digo la verdad, he tenido muchos problemas en Paradox con tablas ligadas mediante Integridad Referencial cuando alguna de ellas se ha fastidiado. En estos casos no vale llevarte del cliente la tabla en cuestión sino todas las relacionadas (aunque lo propio es coger la BD entera). Aún así, hay veces en que es un suplicio el abrir una tabla relacionada a otra corrupta, muchas veces es imposible, y hay que recurrir a ciertas artimañas. En ocasiones me he arrepentido de haber definido ciertas reglas (no te olvides - supongo que lo hace todo el mundo - de guardar una copia de las tablas vacías en perfecto estado, no sólo sirve para realizar nuevas instalaciones sino para casos como estos que te comento).
- A veces, ciertos cambios en una tabla que guarda dependencias con otras, requiere desactivar dichas dependencias, y tienes que seguir un orden en la reestructuración de tablas (desde la última relacionada).
- Según qué casos, el definir "por obligación" reglas de este tipo, más si cabe campos Lookup, hace más lento el volcado masivo de datos (por ejemplo desde otra consulta) puesto que a cada registro insertado, el BDE comprueba en la tabla relacionada que cierto/s valor/es sean válidos. Y, además, muchas veces el definir un campo como Lookup no es una cuestión vital, sino de ayuda al usuario (esto es vital pero no tanto
).
Aparte de todo esto, como dice Madriles, es conveniente crear índices a nivel de la BD; imprescindible una clave primaria para cada tabla, e índices secundarios mantenidos (Mantained) que actúen como claves foráneas hacia otras tablas; y recomendable crear índices secundarios que puedan agilizar las consultas más comunes.