Opiniones de : llave compuesta y velocidad

Hola, vayamos por partes dijo Jack ;-)

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

En principio si, ya que una llave menor es mas optima (cuanto, hay veces que
es muy dificil de medirlo), lo que si ahorraras espacio en el servidor y
esto si puede ser todo un tema.

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

Aca no te comprendi :(

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

Depende, si las busquedas seran por esos campos es una opcion. Recuerda
siempre que la generacion de indices penaliza algunas operaciones como por
ej

Insert - Update - Delete



Maxi
Buenos Aires - Argentina
Desarrollador .NET 3 Estrellas
Microsoft User Group (MUG)



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

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

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

Hola MAXI
Como siempre gracias por tu tiempo , t aclaro lo q quise decir en mi 2da
consulta:

En mi tabla T3 tengo como campos la llave de T1 (c1,c2,c3) y por tanto puedo
obtener todos los registros de T3 partiendo de la tabla T1 algo asi

select T3.* from T1,T3
Where t1.c1=t3.c1 and t1.c2=t3.c2 and t1.c3=t3.c3

Puedo hacer esto gracias a q tengo en T3 una FK a T1, por tanto no necesito
pasar por T2 para esta operacion ya que si no tuviese en T3 un FK a T1
tendria que incluir a T2 en mu consulta que seria algo asi

select T3.* from T1,T2,T3
Where t1.K1= t2.K1 and t2.K2=t3.K3

Me parece que la primera consulta es mas directa que la 2da, y que
optimizaria el tiempo de respuesta aunque ocupe mas espacio Cierto???

GRacias Maxi


"MAXI" wrote in message
news:%23%

Hola, vayamos por partes dijo Jack ;-)

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

En principio si, ya que una llave menor es mas optima (cuanto, hay veces
que es muy dificil de medirlo), lo que si ahorraras espacio en el servidor
y esto si puede ser todo un tema.

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

Aca no te comprendi :(

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

Depende, si las busquedas seran por esos campos es una opcion. Recuerda
siempre que la generacion de indices penaliza algunas operaciones como por
ej

Insert - Update - Delete



Maxi
Buenos Aires - Argentina
Desarrollador .NET 3 Estrellas
Microsoft User Group (MUG)



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

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

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

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

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

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