implicaciones de tener muchas llaves foraneas?

[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