Opiniones de : llave compuesta y velocidad

Solamente asegurate de que el rendimiento de las consultas más habituales
se verá mejorado, preparate un juego de datos como 5 veces lo más grande
que creas que pueda llegar a ser y prueba las páginas leidas con una y
otra alternativa. Es la mejor forma de no equivocarse en un diseño con el
que vivirás el resto de la vida de la aplicación.

si te sirve de algo, yo usé un mecanismo similar con una tabla de
artículos que tenía mil clasificaciones y me fué bastante bien.

Saludos
Miguel Egea

"SergioT" escribió en el mensaje
news:%

Hola Miguel
Gracias por tu Observacion.

Tienes razon en que T1 y T2 tienen relacion 1->N , en realidad lo q estoy
haciendo despues de darle un monton de vueltas al tema es lo siguiente,
haber q t parece:

Este seria el diseño "logico"
T1( c1,c2,c3, otros campos) la llave es: c1+c2+c3 Tabla
Abuela
T2( c1,c2,c3, c4, otros campos) la llave es: c1+c2+c3+c4 Tabla
Padre/hija
T3( c1,c2,c3, c4, c5, otros campos) la llave es: c1+c2+c3+c4+c5

(T1) 1->N (T2) y (T2) 1->N (T3)

Mi diseño fisico o real quedó así:
T1( K1,c1,c2,c3, otros campos) la llave es: K1 Tabla Abuela
T2( K1,K2,c1,c2,c3, c4, otros campos) la llave es: K2 K1 es fk
a T1
T3( K2,K3,c1,c2,c3, c4, c5, otros campos) la llave es: K3 K2 es fk a
T2

La verdad creo un poco de redundancia ya que al final tengo la llave como
un solo campo integer pero mantengo los datos de la llave
principal o natural ademas de la fecha , esto para evitarme joins con la
tabla padre en muchos casos, ya que la mayoria de las consultas serán de
la tabla T2 y serán ordenadas por "parte" de la clave logica o natural de
la tabla T1, por tanto los joins que me quedan son solo a las tablas
"satelite" que tienen descripciones como al catalogo de productos por
ejemplo. Ademas he creado un indice en T2 que contiene parte de la llave
de T1 y que refleja el orden de la mayoria de las consultas.

Que t parece???

Gracias





"Miguel Egea" wrote in message
news:%

Hola sergio, lo que no acabo de ver es que el diseño de la estructura
sea correcto. Si yo lo entiendo bien T1 tiene una relacion 1-N con T2,
por tanto es t2 quien tiene que contener la clave de T1, y lo que veo
que propones es justo al revés, esto no reflejará tu estructura de
datos. por otra parte:

Es deseable claves cuanto más pequeñas mejor, sin embargo, si usar
claves artificiales te va a obligar a hacer joins de muchas tablas lo
que ganas por una parte lo perderás por otra con creces.

En resumen, estudia bien el volumen de datos que tendrá cada tabla y
revisa las consultas que usarás. A lo demás te contesto en linea


"SergioT" escribió en el mensaje
news:

Hola

Una pregunta

tengo una jerarquia de tablas asi:
T1( c1,c2,c3, otros campos) la llave es: c1+c2+c3
Tabla Abuela
T2( c1,c2,c3, c4, otros campos) la llave es: c1+c2+c3+c4
Tabla Padre/hija
T3( c1,c2,c3, c4, c5, otros campos) la llave es: c1+c2+c3+c4+c5
Tabla Hija/nieta

He pensado en cambiar esta estructura a :
T1( c1,c2,c3, otros campos,K1) la llave es:
c1+c2+c3
T2( c1,c2,c3, c4, otros campos,K1,K2) la llave es: K1
T3( c1,c2,c3, c4, c5, otros campos,K2) la llave es: K2

De forma que c1,c2,c3 quedan como datos rebundantes simplemente

Las preguntas son:

1) Al utilizar un solo campo como Llave de registro, ahorro tiempo en
consultas?? es mas option??? o es lo mismo para el sql??

un índice sobre un integer ocupará 4 bytes *fila, si en lugar de uno son
3 el índice ocupará tres veces más espacio y por tanto necesitará 3
veces más páginas, lo que se convertirá algunas veces en 3 veces el
número de lecturas, sin embargo no será todas las veces y dependerá
además mucho del número de registros.
En resumen ,si la llave es más pequeña es mejor para las búsquedas, pero
no siempre se justifica disminuir el tamaño de la clave.

2) Al no quitar de T3 la referencia a T1 puedo obtener datos de T1 sin
tener que incluir a T2 en la consulta, por tanto mejoro el rendimiento
cierto????

En aquellas consultas en las que no tengas que incluir t2 esto hará que
tengas una tabla menos en el join , y por tanto si mejorará el
rendimiento (potencialmente).

3) Sabienqdo que utilizaré mucho los campos Cx de T3 me conviene volver
a cada uno de ellos un indice en T3 ???
gracias

Lo mejor es ver las consultas y después decidir los índices, indices
independientes sobre cada columna igual ayudan o igual no son
suficientes. Siempre dependerá de los arguméntos de búsqueda (SARG).


-
Miguel Egea Gómez
Microsoft SQL-Server MVP, MCSD, MCAD,MCT
Webmaster de PortalSql.Com
¿Te interesa participar en las reuniones
del grupo de Usuarios de SQL-Server y .NET
Se harán en levante de España, (Alicante o Murcia)?