![]() |
![]() |
![]() |
![]() |
![]() |
FTP | ![]() |
![]() |
CCD | ![]() |
![]() |
Buscar | ![]() |
![]() |
Trucos | ![]() |
![]() |
Trabajo | ![]() |
![]() |
Foros | ![]() |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
![]() |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
|||
|
|||
implicaciones de tener muchas llaves foraneas?
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?? Última edición por erickperez6 fecha: 18-10-2010 a las 18:28:01. Razón: indicando la base de datos |
#2
|
||||
|
||||
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. |
#3
|
||||
|
||||
Cita:
![]() ![]() // Saludos |
#4
|
||||
|
||||
Cita:
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! ![]() ![]() ![]() Saludos, |
#5
|
|||
|
|||
![]() 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 |
#6
|
||||
|
||||
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. |
#7
|
|||
|
|||
Cita:
Cita:
[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: Cita:
Última edición por erickperez6 fecha: 18-10-2010 a las 22:28:18. |
#8
|
|||
|
|||
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.
__________________
Luis Fernando Buelvas T. |
#9
|
||||
|
||||
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 ![]() ![]() 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, |
#10
|
||||
|
||||
Cita:
Cita:
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.
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi ![]() P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
#11
|
|||
|
|||
Cita:
Con esto no posteo mas... ![]() ![]() ![]() Saludos |
#12
|
|||
|
|||
Cita:
Cita:
![]() Cita:
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. |
![]() |
|
|
![]() |
||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Problemas con llaves foraneas | jcrg666 | MySQL | 1 | 01-04-2010 00:41:36 |
Maneja llaves foraneas , problemitas! | richardxxx | Varios | 1 | 07-11-2008 22:42:03 |
LLaves foraneas... | Luis Castillo | SQL | 2 | 13-11-2005 18:45:34 |
Llaves Foraneas | RainFall | MySQL | 1 | 26-07-2004 04:19:28 |
Llaves foraneas en BDD distintas | StartKill | Firebird e Interbase | 7 | 31-01-2004 01:14:01 |
![]() |
|