[[Delphius]]

Empezado por erickperez6

Estoy totalmente de acuerdo, opino que estas serian la razones mas importante de apoyarse siempre de todas las llaves foraneas necesarias al momento de diseñar nuestra base de datos.

El punto es definir cuando se tienen la cantidad necesaria y cuando se pasa al punto de la redundancia.

Empezado por erickperez6

La verdad es que no me imagino como se pueden crear llaves foraneas que no se necesiten o que no cumpliran con ningun objetivo, pero veamos un caso hipotetico practico simple:

[transaccionesEncabezado]
EncabezadoId
EncabezadoFecha
clienteId
vendedorId
usuarioId
sucursalId

[transaccionesDetalle]
EncabezadoId
productoId
unidadId
productoCantidad
productoPrecio

Caso 1:
relacion foranea1: tablas transaccionesEncabezado y transaccionesDetalle con EncabezadoId (maestro / detalle de las transacciones)
... fin de las relaciones

Caso 2:
relacion foranea1: tablas transaccionesEncabezado y transaccionesDetalle con EncabezadoId (maestro / detalle de las transacciones)
relacion foranea2: tablas transaccionesEncabezado y clientes con clienteId
relacion foranea3: tablas transaccionesEncabezado y vendedores con vendedorId
relacion foranea4: tablas transaccionesEncabezado y usuarios con usuarioId
relacion foranea5: tablas transaccionesEncabezado y sucursales con sucursalId
relacion foranea6: tablas transaccionesDetalle y productos con productoId
relacion foranea7: tablas transaccionesDetalle y unidades con unidadId
... fin de las relaciones

Aunque sean mas, la verdad es que siento que puedo dormir mas tranquilo con el segundo caso

Pues yo dormiría más cómodo y tranquilo con el primer caso. Hay menos lío y quizá sea un diseño más estable. Cuanto mayor sea la cantidad de claves foráneas, más complicado es el diseño general de la base de datos y existe una creciente peligrosidad de la presencia de ciclos en las relaciones.

Con cada clave foránea que se añade la probabilidad de que exista un ciclo aumenta... y déjame decirte que en términos estadísticos por cada 2 claves foráneas en una tabla pueden llegar a esperarse 1 ciclo. Para tu ejemplo, es posible esperar cerca de 4 potenciales ciclos entre esas dos tablas y otras restantes.

Empezado por erickperez6

Con lo que me referia al tema inicial es por qué dejar intencionalmente una relacion como el caso 1? ¿a cambio de que sacrificar la integridad de la informacion?... sera mejor performance de la db? velocidad? menos corrupcion? otras tecnicas de mantener la integridad? algo que desconozco? o simplemente es un mal diseño de la base de datos y me estoy complicando mas de la cuenta... todo viene por lo que señale al principio del post:

NO necesariamente se está poniendo en peligro la integridad de información con el 1er caso. Ni me atrevería a afirmar que tener 2 o más claves foráneas lo van a mejorar...
Un mal diseño es un mal diseño, y no hay integridad que se salve de ésto.

Se puede tener males diseños aún con pocas claves foráneas e incluso logrando un diseño lo más simple posible en donde en promedio las tablas "detalles" sólo cuenten con 1 clave foránea. Y también se pueden tener malos diseños con tablas con más de una clave foránea. Pero es mucho más fácil meter las dos patas cuando tenemos más relaciones y más claves foráneas entre menos tablas.

No pasa tanto por la perfomance sino de un adecuado equilibrio de normalización de la base de datos. La teoría de integridad referencial es una teoría fuerte y funciona a la perfección... que una tabla esté tan múltiple relacionada llevará a que el motor aplique controles redundantes y que se ramificarán por las tablas dependientes, y si... afectará a la perfomance... aunque a nuestros ojos sabiendo el poder de Firebird nos resultará, en ocasiones, despreciable.
¿Si la teoría satisface un adecuado vínculo con una clave es necesario añadir otras más, con otras entidades, y que éstas también lleven a la peligrosidad de llevar hacia un ciclo de dependencia mutua?

El ejemplo que expones a mi modo de ver es para un caso de desnormalización que de normalización. Los casos de desnormalización, como bien lo indica su nombre salen de los esquemas normales y si hay que llevarlo a la práctica debe ponerse en su debido equilibrio.

El ejemplo que pones invita a pensar a romper las reglas normales... re-adaptando el diseño es posible eliminar entre un 1/3 y la mitad de todas las claves foráneas de esa tabla.

Aún así, los casos para el común de los mortales las reglas normales son más que suficientes y garantizan una actividad mucho más llevadera, sana, simple y segura.

Empezado por Gallosuarez

Casimiro y Luis Fernando:

Bueno, en todo caso no solo sería a mi a quien tienen que convencer de que estoy equivocado, sino a Holger Klemt (creador de IBExpert, y reconocido desarrollador e impulsor de Firebird). Por cierto, tengo aquí a la mano el correo que recibí de IBExpert KG (empresa de Holger Klemt), invitando a las conferencias que se llevarán a cabo del 11 al 13 de Noviembre de 2010 en Bremen, Alemania. Entre las diferentes conferencias que se van a impartir hay una en particular que me llama la atención:

Holger Klemt: Part-time foreign keys: using flexible triggers to replace declarative foreign keys

(Holger Klemt: Llaves Foráneas de Tiempo Parcial: usando disparadores flexibles para reemplazar la declaración de Llaves Foráneas).

Se aproxima la fecha y mis finanzas no andan muy bien.... además de que mi esposa y yo estamos esperando a nuestro tercer bebé... bueno ... tal vez.... para la próxima vez...

Sería interesante si alguien del foro pudiera ir y nos platicara mas, no solo lo de esta conferencia en particular, si no de todas las que van a presentar.

Saludos,
Gerardo Suárez Trejo.

P.D. Si gustan les puedo avanzar dicho correo para que no crean que hablo solo por hablar, o mejor aún, entren a la página de IBExpert y cerciórence por uds mismos que no hablo mentiras. Saludos nuevamente....

Como he dicho al final de mi mensaje a erickperez6, a lo que apuntas tu y Holger Klemt son a casos un tanto ya fuera de lo normal y en donde la desnormalización y la extra y excesiva flexibilidad tienen mayor peso e importancia que el esquema tradicional y que funciona efectivamente: bases de datos relacionales.

Para la gran amplísima mayoría de las situaciones y las actividades cotidianas en donde se requiera de bases de datos con el esquema basado en las claves foráneas (las justas y necesarias) y las reglas de integridad referencial se consigue un diseño robusto, estable y seguro.

No creo que Holger Klemt esté en contra de las claves foráneas... si las claves foráneas no fueran útiles, como lo parecieras vender la idea, hace tiempo que se habrían eliminado y estaríamos trabajando en otros esquemas. ¿Digo no?

Saludos,