Cuestion de gustos

[hgiacobone]

En referencia a DB tipo Paradox:
¿Qué es mejor con respecto a las relaciones Maestro-Detalle?
Definirla en la tabla cundo se define la estructura y demás indices.
o
Utilizar la propiedad MasterSource en, por ej, la Ttable que esta en un DataModule.


¿Qué es mejor con respecto a los campos Lookup?
Establecer los campos Lookup mediante el DBD “dentro” de la tabla.
o
Hacerlo en la Ttable que esta en un DataModule.

[madriles]

no se que es lo que los demas opinaran, pero yo, personalmente, prefiero definir los indices cuando creo la tabla .
por supuesto que depende del uso que se vaya a hacer. en algunas ocasiones , en que vas a necesitar utilizar por ejemplo 10 indices para una sola tabla es mas aconsejable usar MasterSource, consultas SQL creadas en tiempo de ejecucion...
lo dicho, no hay una forma mejor o peor, todo depende de lo que en cada momento vayas a necesitar
un saludo

[andres1569]

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.

[hgiacobone]

Gracias por contestar amigo mio.

Posteado originalmente por andres1569
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...

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; ...

O sea que definir en la DB, es mas un problema que una solución. Pensaba que al hacerlo, era como en el Diccionari de Datos con los campos, que uno define las propiedades por defecto y al insertar el componente DBEdit en un Form, "arrastra" esas propiedades, facilitando y agilizando el diseño.
En estos casos, ahora, además del tiempo que perdí definiendo todo en la DB, tengo que repetirlo en el entorno de desarrollo, volviendo a perder tiempo.
Digamos que me he metido en un gran lio.

- Si te digo la verdad, he tenido muchos problemas en Paradox con tablas ligadas mediante Integridad Referencial cuando alguna de ellas se ha fastidiado...

A VECES LA VERDAD ES MATADORA...

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.

Perdonen mi ignorancia, pero ¿A que llaman "índices secundarios mantenidos (Mantained) que actúen como claves foráneas hacia otras tablas"?

[[Lepe]]

Lo de foránea supongo que viene de Foreign Key ( Clave extranjera o ajena)

una traducción un poco "así"

Yo soy español, y tambien me quedé como tú cuando leí eso de foranea

[andres1569]

hgiacobone escribió:

Digamos que me he metido en un gran lio.

No es un lío tan grande, y si otros hemos pasado por ahí ... pero efectivamente, el trabajo realizado a nivel de base de datos no es reconocido por Delphi automáticamente, salvo como dije que te ahorras la creación de índices necesarios y el no tener que controlar ciertas restricciones desde tu aplicación.

A VECES LA VERDAD ES MATADORA

... pero cura ... (aunque si estás muerto de poco te sirve ).

Ya imaginaba que iba a aportarte más zozobra que luz con mi mensaje, preferí no darte ningún consejo sino exponerte los pros y los contras.

Sin embargo, no creo que sea ese un problema exclusivo de Paradox, en general cualquier restricción de integridad en una base de datos complica su reparación en caso de corrupción, por el hecho de que no puedes tratar cada tabla como un conjunto independiente. Digamos que lo que es agradable cuando todo funciona bien se vuelve un fastidio cuando deja de ir bien. Pero aún puedes trabajar a la vieja usanza, sin definir dichas reglas y controlándolas desde la aplicación.

A que llaman "índices secundarios mantenidos (Mantained) que actúen como claves foráneas hacia otras tablas

Cuando creas un índice secundario, si le indicas (aunque se creen así por defecto) que sea mantenido, el motor BDE se encarga de actualizarlo cada vez que tiene lugar una inserción, modificación o borrado, de forma que el índice está siempre actualizado y listo para poder ser usado, sin más trabajo por tu parte.

Lo de clave foranea hacia otras tablas indica que el índice se aplica a un campo que sirve de nexo con otra tabla. Ejemplo: Si en cabeceras de facturas (CABFACTU.DB) tenemos el campo ID_FACTURA que hace de clave primaria en esta tabla, en lineas de factura (LINFACTU.DB) tendremos un campo ID_FACTURA sobre el que definimos un índice secundario, en esta segunda tabla ID_FACTURA es una clave foranea porque apunta a otra tabla, haciendo de nexo. Si has definido Integridad Referencial, el Database Desktop te genera ese índice, si no lo debes definir tú. De esta forma, cuando enlaces desde Delphi ambas tablas mediante Master-Detail la selección de registros en la tabla de lineas será inmediata (gracias al índice) lo mismo que cuando realices una consulta que ligue ambas tablas.

[delphi.com.ar]

Desconozco la realidad del Paradox, pero creo que sirve agregar:
En muchos sistemas, sobre todo en los sistemas muy grandes, es muy común que se accedan y modifiquen los mismos datos de lugares diferentes desarrollado por personas diferentes, teniendo relaciones, PK, UK, y controles a nivel de Checks y triggers, evitarías que ingresen datos erróneos en tu base de datos, cualquier sistema certificado requiere que se creen todas las restricciones posibles del lado del motor.
Además uno de los primeros pasos del diseño del sistema, es crear un diagrama entidad-relación de las tablas que contendrán los datos, porqué no crearlos en la base de datos??


Saludos!