implicaciones de tener muchas llaves foraneas?

[Neftali [Germán.Estévez]]

Empezado por erickperez6

Me gustaria saber si tener una base de datos fuertemente diseñada con llaves foraneas puede incidir con el decrecimiento del performance de la db?

Sí.

Empezado por erickperez6

Estoy claro que una base de datos ampliamente relacionada con llaves foraneas decrece la velocidad en los insert, update, delete por lo constantes chequeos/cambios que tiene que hacer antes de aplicar los cambios

La lógica es correcta.
Otro problema (y gordo) es lo que eso implica.

Es algo así como decir: "Si a un coche le quitamos los frenos, las luces, los asientos, los cinturones,... ¿Correrá más?"

RESPUESTA: Sí. Pesa menos, por lo tanto correrá más. El problema vendrá cuando tengas que parar/frenar...

Si quitas TODAS las foráneas de una Base de datos habrá algunas operaciones que irán más rápido, cierto; El problema son las prestaciones que estás perdiendo a cambios.

Si hablamos de "casos especiales" y por lo tanto no generalizamos, puede ser conveniente "desactivar claves foráneas" para ganar velocidad, como puede ser un proceso de carga masiva o de copia de datos; Pero simplemente porque se asumen unas condiciones (los datos son correctos y vienen de una fuente donde sí están relacionados con claves) que so se pueden asumir en otros casos y deben tratarse como especiales. De ahí, que muchas bases de Datos (como alguien ha comentado) tengan la opción de desactivar estas comprobaciones de forma momentánea (desactivar, no eliminar).

He visto Base de Datos sin foráneas, donde había comprobaciones mediante triggers y algunas otras donde se hacían por programa (delphi); Al final, el tiempo de comprobación hay que "perderlo" igual, sea en el Trigger o en el código Delphi.
Salvo que haya una razón para no hacerlo mediante una clave foránea, no veo razón para programar una cosa que ya está hecha.

[cloayza]

Empezado por Neftali

Es algo así como decir: "Si a un coche le quitamos los frenos, las luces, los asientos, los cinturones,... ¿Correrá más?"

RESPUESTA: Sí. Pesa menos, por lo tanto correrá más. El problema vendrá cuando tengas que parar/frenar...

!!!QUE EJEMPLO!!!

Con esto no posteo mas...

Saludos

[erickperez6]

lbuelvas

Para erickperez6, puedo garantizar que el sistema que mencionas que usa pocas llaves foraneas no es para bases de datos de gran tamaño y si lo fuera el rendimiento no sería el ideal, algunos fabricantes de software exigen al cliente para solventar los problemas de rendimiento el utilizar equipos más rápidos.

Otro asunto es que cuando haces un sistema que lo tienen muchos clientes es más fácil mantener los problemas de diseño que corregir e ir a actualizar aplicativos a esa cantidad de clientes.

Estoy deacuerdo, quizas ellos tendran sus razones para hacer esto

Casimiro Notevi

Estamos hablando, supongo, de "casos normales", y lo normal es usar una clave foránea, pongamos un simple ejemplo:
tabla personas (idPersona, nombre, domicilio, pais, sueldo);
tabla paises (idPais, nombre);
Lo normal es que exista una relación entre idPais (tabla paises) y pais (tabla personas).
Nos evitamos asignar una persona a un país inexistente, nos evitamos borrar un país que tiene asignado alguna persona, etc. eso es lo normal, ¿o acaso estamos hablando de otra cosa y no me he enterado?

Exactamente de este tema hablamos

Delphius

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.

Si, tienes razon en que a mayor llaves foraneas mas complicado es el diseño en general, obviamente. Tambien conozco lo que son los conflictos de dependencia que pueden desencadenar algunas llaves foraneas por causa de un mal diseño, pero no entiendo bien a que te refieres con los ciclos, hablamos de lo mismo?

En fin, en el ejemplillo expuesto sin extrapolarme a situaciones mas complejas, yo me quedaria con el caso2, creo que no seria prudente dejar huerfanos algunas asociaciones que se pudiera realizar por medio de las llaves foraneas, es como dice Casimiro, asi nos evitamos de asociar codigos que no existen o que algun usuario comience a cambiar o eliminar codigos de clientes, productos, sucursales, vendedores que estan representados en estas dos tablas.