implicaciones de tener muchas llaves foraneas?

[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?

Me surgio la duda cuando estaba observando dias atras el diseño de una base de datos (obviamente en firebire) de un producto muy terminado y con muchos años en el mercando y observe que utiliza muy poco las llaves foraneas, solo en caso excepcionales como en tablas de maestro / detalle de transacciones, despues nada de llaves foraneas.

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, pero tambien tambien se ven afectados otros factores??

[Casimiro Notevi]

La cantidad de claves foráneas deben ser las que se necesiten, ni más ni menos. No vas a dejar un campo sin su clave foránea a otra tabla, hacer esas cosas son del pasado, cuando no existían las bases de datos relacionales.
No te preocupes por la cantidad de claves, salvo que tengas tropecientas mil.

[lbuelvas]

Las llaves foraneas garantizan que haya integridad en la informacion, es decir, que un campo o campos de un registro tengan un valor de referncia en un registro de otra tabla.

Una llave foranea es en el fondo un indice y como tal te genera mas espacio en disco y un tiempo de procesamiento cuando insertas, modificas o borras registros.

La ventaja es que las consultas pueden ser en la mayoria de las ocasiones mucho mas efcientes porque esos indices los utiliza el motor para elabora el plan que debe seguir para recuperar información de la base de datos.

Sin llaves foraneas se incrementa la complejidad del aplicativo porque tendrian que ponerse esos controles del lado del software que estes desarrollando para mantener la integridad de la información y además el aplicativo iria mas lento porque al verificar la existencia de un registro en una tabla con el valor que pretendes insertar en otra, la base de datos tendría que hacer un recorrido sobre toda la tabla hasta encontrar dicho valor, si esta tabla es de cientos de miles de registros sería catastrófico.

Creo que lo mejor es el uso de las llaves primarias y foraneas, sin embargo, esperamos otro tipo de opiniones para ver en que casos sería aplicable dejar de usar total o parcialmente las llaves foráneas.

[[Delphius]]

Hola,

A ver... disculpa si le doy un "pequeño" giro a tu pregunta, aunque creo que lo que diré no es algo demasiado nuevo que no se haya dicho ya en el hilo.

¿Que ventaja tiene tener más claves foráneas de las necesarias para vincular las tablas? Si una clave foránea vincula un algo con otro algo... ¿con que algo más se pretende vincular al algo analizado (cualquier tabla en cuestión)?

La respuesta es evidente: si todo los algo están ya relacionados... ¿Para que más? ¿Hay otra cosa o algo más que no esté vinculado? ¿Crees que te aporta en algo? (creo que tengo que buscas sinónimos ... se me hizo un trabalenguas )

Una clave foránea cumple un sólo objetivo: vincular la tabla esclava o detalle con la maestra. No sirve para ninguna otra cosa.

No concibo otro propósito, ni me imagino alguna utilidad ni la manera en como añadir más claves foráneas que las necesarias.

Me atrevería a apostar que pretender meter claves foráneas en todos lados es motivo de un mal diseño o de una mala comprensión de los conceptos de la teoría de base de datos... con todo respeto.

Saludos,

[roman]

Empezado por Casimiro Notevi

La cantidad de claves foráneas deben ser las que se necesiten, ni más ni menos.

Creo que es la respuesta más precisa y concisa. Si dos tablas se relacionan se necesita una llave foránea, si no, no.

// Saludos

[[Delphius]]

Empezado por roman

Creo que es la respuesta más precisa y concisa. Si dos tablas se relacionan se necesita una llave foránea, si no, no.

// Saludos

Pos si, es breve y puntual.

Ahora bien, yo me inclino a pensar, con todo respeto, a que erickperez6 quizá esté confundiendo (o más posiblemente, mezclando) el concepto de clave foránea con algún otro. Por ello lancé el trabalenguas... para mi que hay algo que no está del todo claro.

¡y que va... que ya estoy hecho un disco rayado! ¡que algo tengo con la palabra algo!

Saludos,

[erickperez6]

lbuelvas:

La ventaja es que las consultas pueden ser en la mayoria de las ocasiones mucho mas efcientes porque esos indices los utiliza el motor para elabora el plan que debe seguir para recuperar información de la base de datos.

Sin llaves foraneas se incrementa la complejidad del aplicativo porque tendrian que ponerse esos controles del lado del software que estes desarrollando para mantener la integridad de la información y además el aplicativo iria mas lento porque al verificar la existencia de un registro en una tabla con el valor que pretendes insertar en otra, la base de datos tendría que hacer un recorrido sobre toda la tabla hasta encontrar dicho valor, si esta tabla es de cientos de miles de registros sería catastrófico.

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.

Delphius:

Me atrevería a apostar que pretender meter claves foráneas en todos lados es motivo de un mal diseño o de una mala comprensión de los conceptos de la teoría de base de datos... con todo respeto.

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

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:

Me surgio la duda cuando estaba observando dias atras el diseño de una base de datos (obviamente en firebird) de un producto muy terminado y con muchos años en el mercando y observe que utiliza muy poco las llaves foraneas, solo en caso excepcionales como en tablas de maestro / detalle de transacciones (Caso 1), despues nada de llaves foraneas.

[Gallosuarez]

Señores:

Disculpen en disentir con la mayoría de Uds. en cuanto a que las llaves foráneas se deben de declarar implícitamente si se desea relacionar dos tablas. Existe otra técnica de relacionar tablas utilizando disparadores. Siiii ya se que van a decir que esto conlleva a un mayor esfuerzo en la programación, sin embargo el beneficio de hacer esto es justamente lo que decía Erick Pérez (quien inició este hilo), en cuanto una mejora significativa en cuanto al desempeño de la base de datos cuando hay inserciones y actualizaciones masivas.

Saludos,

Gerardo Suárez Trejo

[Casimiro Notevi]

Para nada se puede estar de acuerdo con eso, amigo Gallosuarez, las bases de datos relacionales tienen ese nombre precisamente por eso, por las relaciones. Lo que has comentado sería "reinventar la rueda" puesto que la propia base de datos ya controla esas cosas precisamente con las relaciones.
No hay ningún problema de desempeño por usar las relaciones (claves foráneas) y tal vez sí que exista algo menos de desempeño en la propuesta que has indicado. Además de que está el problema de tener que controlarlo todo y que no se te olvide ni te equivoques. De la otra manera (claves foráneas) el trabajo está hecho porque lo hace la propia base de datos.

[lbuelvas]

Para Gallosuarez, cuando hay inserciones masivas como por ejemplo cuando se está migrando información para una base de datos antes de colocarla en producción se pueden quitar (no recuerdo en firebird si se pueden deshabilitar como con los indices) y luego colocarlas, es mas eficiente crear una llave o indice cuando ya están montados los datos (y la estructura queda mas balanceada) que definir la llave o indice y luego montar los datos.

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.

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

[lbuelvas]

Respondiendo a Gallosuarez, claro que se pueden manejar la integridad referencial via triggers pero implica el que se definan indices para asuntos de rendimiento.

Hay algunos casos en los que ciertas tablas no son buena idea crearlas aún en aras de la flexibilidad en la parametrización de aplicaciones, por ejemplo, crear una tabla para "estado civil" sabiendo que los valores para dicha tabla son pocos y dificlmente cambian. Algunos desarrolladores crean la tabla "estado civil" y crean una llave foranea para el campo"empleado"."estado_civil".

Hay un tema que se llama la "selectividad", lo ideal es que por cada valor clave de la tabla maestro haya una distribución de registros en la tabla detalle, por ejemplo, un campo "empleado"."codigo_ciudad" podría tener esa distribución, pero un campo "cliente"."sexo" no lo tendria porque por cada sexo ('M'masculino,'F'emenino, 'I'ndeterminado (se presentan algunos casos donde al bebe no se le puede dictaminar su sexo, caso hermafrodita)) la distribucion de registros es 50% y 50%, una llave foránea en este caso puede ser una mala decisión y consultas cuya clausula where hagan referencia a este campo no serían tan eficientes.

Una solución es crear una tabla para conservar este tipo de valores, en algunos casos utilizo algo como esto:

Código SQL [-]
CREATE TABLE TS_LISTA_VALORES (
    NOMBRE_CAMPO  VARCHAR(40) NOT NULL,
    VALOR_CORTO   VARCHAR(40) NOT NULL,
    VALOR_LARGO   VARCHAR(255)
);

y se crean triggers para el caso "cliente"."sexo" que verifiquen la existencia de valores en esa tabla. En lo personal, si una lista de valores que puede contener un campo es menor o igual que 20 datos los mando a la tabla anterior, si es mayor de 20 lo mando a una tabla y le creosu respectiva llave foránea.

Para ampliar la cosa tendriamos que irnos al campo de las desnormalizaciones pero saldriamos del interes de este hilo.

[lbuelvas]

Hay una página que sigo desde hace muchos años dela cual he aprendido muchísimo, su formato no es muy bonito pero su contenido es la más alta calidad.

http://www.tdan.com/

Esta publicación es mensual, pueden entrar a "Search" para consultar artículos. Hay buenas referencias para diseño de bases de datos, normalización y desnormalizacón.

[[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,

[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?

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

[Gallosuarez]

Señores:

Trato de contestar (en forma apretada) a todos los compañeros.

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, pero tambien tambien se ven afectados otros factores??

No perdamos de vista la pregunta que originó todo esto, ¿vale?.

Empezado por Casimiro Notevi

No hay ningún problema de desempeño por usar las relaciones (claves foráneas) y tal vez sí que exista algo menos de desempeño en la propuesta que has indicado. Además de que está el problema de tener que controlarlo todo y que no se te olvide ni te equivoques. De la otra manera (claves foráneas) el trabajo está hecho porque lo hace la propia base de datos.

A decir verdad (en base a pruebas que nosotros hemos hecho), podemos decir exactamente lo contrario de lo que tu afirmas. Otra cosa, nunca propuse eliminar llaves foraneas en aras de un mejor desempeño y a costa de la estabilidad de la base de datos (no es argumento tuyo pero aprovecho para contesta a otro forista).

Empezado por 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.

Por nuestra parte, no podemos asegurar nada. Primero tendríamos que analizar el código y hacer algunas pruebas para despues aventurarnos a decir un diagnóstico. El que haya pocas llaves foráneas no siempre nos dice algo en cuanto a la capacidad de almacenamiento y en cuanto a la capacidad de desempeño de la base de datos (vamos, no se puede aplicar esto como una regla general).

Empezado por Casimiro Notevi

Estamos hablando, supongo, de "casos normales", y lo normal es usar una clave foránea, ...

Ah, caray , ¿donde está la línea divisoria entre los "casos normales" y los que no lo son. Permíteme abundar en esto, hace algún tiempo un compañero del foro preguntaba sobre la necesidad de tener un campo computado pero que al mismo tiempo fuera como un procedimiento almacenado. Tal vez les sorprenda a algunos (tal vez no), pero se puede hacer que un campo computado sea el resultado de un procedimiento almacenado (comprobado hasta la versión 2.1, no se si se pueda hacer en la 2.5). Bueno, no se si esto resolvía el problema del compañero, pero bajo tu óptica (y la de algunos otros compañeros del foro), no lo podríamos utilizar porque no es una solución "normal", aunque esto nos resolviera el problema (ojo, mis preceptos al momento de diseñar la base de datos es que primero está la seguridad y la estabilidad y después viene el desempeño), es decir todo lo demás es válido teniendo como base estos preceptos (con esto no quiero decir que las cosas se hagan de esta manera, lo que quiero decir es que esto me ha funcionado a mi y a lo mejor le podría ser útil a alguién mas) .

Menciono otro caso: ¿cuantos de nosotros (hablando a nivel foro) ha utilizado el RDB$DB_KEY para hacer actualizaciones masivas [mas de 200 mil registros] en tablas maestro detalle? Lo "común" (cambiando el término propositivamente por el de "normal"), es utilizar lo que todos nosotras ya sabemos hacer. Sin embargo, esta herramienta es una maravilla y, en nuestro caso, nos permitió bajar el tiempo de ejecución de una actualización de 2:09 hrs a 7 segundos.

Por último, el utilizar llaves foraneas de tiempo parcial utilizando disparadores (creo que es la mejor solución a la que ha llegado Holger Klempt y un servidor por separado, aunque les puedo asegurar que la solución que él va a presentar será mucho mas elegante y robusta), es obvio puesto que él es un viejo zorro de mar (expresión que nosotros utilizamos para decir que alguíen es poseedor de una gran y basta experiencia), y yo soy apenas un pobre aficionado. Por cierto, permítanme explicar un poco mas: al desactivar las llaves foraneas en forma temporal solo cuando uno lo desee (al principio las habíamos eliminado, sin embargo despues nos percatamos que se pueden solo desactivar y con esto no perdiamos ningún de las grandes beneficios que éstas nos otorgan), se traduce en gran beneficio en inserciones, actualizaciones y eliminaciones masivas, sin que esto perjudique o afecta de otra manera a nuestra base de datos.

Con todo lo anterior contesto de forma implicita a Neftali y a todos los demás.

Bueno es todo por el momento, espero que nada de esto sea un debate inutil. Tambien espero que algunos se animen a probar otras técnicas de programación, aunque salgan de lo "comun" y de lo "normalmente" prestablacido (tomando siempre en cuanta los preceptos antes mencionados para evitar cualquier problema a futuro)

Saludos,
Gerardo Suárez Trejo

[Casimiro Notevi]

Bueno, pero lo que quiero decir, aprovechando el ejemplo de Neftalí, es que no se van a quitar los frenos para que corra más.
Evidentemente, cuanto más cosas, más lento (mejor dicho: menos rápido), pero no vale la pena quitarle los frenos, ponerle ruedas de bicicleta, etc.
Puestos a aumentar el rendimiento, podemos crear sólo una tabla con 3 campos y no insertar más de 10 registros, ya verás lo rápida que es la base de datos cuando se hagan consultas