duda respecto a indices naturales y artificiales

12/08/2007 - 19:47 por Dany | Informe spam
Amigos, estoy iniciando un proyecto en una empresa pero estoy en una duda respecto a dos tablas de
la BD que tienen alto grado de transacionabilidad y a la vez consultada constantemente.
Son dos tablas que conformar Maestro - Detalle de las cuales la tabla maestro va a contener un
aproximado de 200,000 registros anuales y el detalle va a contener algo de 30 lineas promedio por
cada linea en la cabecera esto nos da una aproximado de 6,000,000 registro en esta tabla de detalle.

Estuve pensando generar un primary Key por dos campos en las dos tablas que seria Año+NroTransaccion
(Char 4 + char(6)) y a la vez estos serian sus campos relacionables pero, lei tambien un articulo en
portalsql respecto al tema de los indices naturales vs indices artificiales donde comentaban que
tener un campo entero como primary key seria mucho mas optimo que hacerlo mediante los indices
compuestos.

Que me recomiendan Uds. por las experiencias que tienen.

si usar un indice simple con campo entero o seguir usando los clasicos indices compuestos???

cual Join seria mas rapido Año+nrotransaccion o Solamente nrotransaccion???

Gracias

Dany Acosta.

Preguntas similare

Leer las respuestas

#1 Salvador Ramos
12/08/2007 - 20:27 | Informe spam
Hola,

Te iba a recomendar precisamente el artículo que has leído :-)

Ya en tu caso concreto, yo aplicaría el Año + NroTransacción, que es tu
clave natural, pero en vez de almacenarla en CHAR(4) y CHAR(6), almacenaría
cada uno de ellos en un INTEGER.
Aunque evidentemente la join sería más si la PK fuese una sola columna
integer en vez de dos. Con el volumen de datos que indicas no creo que la
penalización sea excesiva, creo que no lo vas a notar prácticamente. Ahora,
como bien has visto en el artículo, hay diversas opiniones, finalmente
deberás decidir tu.

Un saludo
Salvador Ramos

www.helpdna.net (información sobre SQL Server y Microsoft .Net)
www.helpdna.net/acerca_de_salvador_ramos.htm


"Dany" escribió en el mensaje
news:
Amigos, estoy iniciando un proyecto en una empresa pero estoy en una duda
respecto a dos tablas de la BD que tienen alto grado de transacionabilidad
y a la vez consultada constantemente.
Son dos tablas que conformar Maestro - Detalle de las cuales la tabla
maestro va a contener un aproximado de 200,000 registros anuales y el
detalle va a contener algo de 30 lineas promedio por cada linea en la
cabecera esto nos da una aproximado de 6,000,000 registro en esta tabla de
detalle.

Estuve pensando generar un primary Key por dos campos en las dos tablas
que seria Año+NroTransaccion (Char 4 + char(6)) y a la vez estos serian
sus campos relacionables pero, lei tambien un articulo en portalsql
respecto al tema de los indices naturales vs indices artificiales donde
comentaban que tener un campo entero como primary key seria mucho mas
optimo que hacerlo mediante los indices compuestos.

Que me recomiendan Uds. por las experiencias que tienen.

si usar un indice simple con campo entero o seguir usando los clasicos
indices compuestos???

cual Join seria mas rapido Año+nrotransaccion o Solamente
nrotransaccion???

Gracias

Dany Acosta.

Respuesta Responder a este mensaje
#2 principiante
12/08/2007 - 22:36 | Informe spam
Eso no es mucho para SQL Server. Yo tengo un sistema de contabilidad aunque
con transacciones separadas por tipo de documento en pares
encabezado/detalle. Pero la cantidad de registros de algunos tipos excede
bastante a lo que citas y usa precisamente claves naturales, anio+secuencia
tipo char. No creo que tengas ningun problema siempre y cuando no haya otros
factores agregados ( como exceso de otros índices o triggers complicados,
etc).

Jose TH

"Dany" escribió en el mensaje
news:
Amigos, estoy iniciando un proyecto en una empresa pero estoy en una duda
respecto a dos tablas de la BD que tienen alto grado de transacionabilidad
y a la vez consultada constantemente.
Son dos tablas que conformar Maestro - Detalle de las cuales la tabla
maestro va a contener un aproximado de 200,000 registros anuales y el
detalle va a contener algo de 30 lineas promedio por cada linea en la
cabecera esto nos da una aproximado de 6,000,000 registro en esta tabla de
detalle.

Estuve pensando generar un primary Key por dos campos en las dos tablas
que seria Año+NroTransaccion (Char 4 + char(6)) y a la vez estos serian
sus campos relacionables pero, lei tambien un articulo en portalsql
respecto al tema de los indices naturales vs indices artificiales donde
comentaban que tener un campo entero como primary key seria mucho mas
optimo que hacerlo mediante los indices compuestos.

Que me recomiendan Uds. por las experiencias que tienen.

si usar un indice simple con campo entero o seguir usando los clasicos
indices compuestos???

cual Join seria mas rapido Año+nrotransaccion o Solamente
nrotransaccion???

Gracias

Dany Acosta.

Respuesta Responder a este mensaje
#3 Carlos Sacristan
13/08/2007 - 12:18 | Informe spam
Me suena ese artículo... ¿por qué será? :-)

Yo personalmente, si la clave natural no es muy ancha (muchos campos),
prefiero usarla a tener que crear una artificial. En tu caso, y siguiendo un
poco la sugerencia de Salva, creo que sería bastante eficiente tener como
clave natural esos dos campos, pero en vez de dos INT, el año entraría de
sobra en un SMALLINT (reduciendo el tamaño del índice), siendo el nº de
transacción efectivamente un INT.

Con el volumen de datos que comentas no hay problema para SQL Server

"Dany" escribió en el mensaje
news:
Amigos, estoy iniciando un proyecto en una empresa pero estoy en una duda
respecto a dos tablas de la BD que tienen alto grado de transacionabilidad
y a la vez consultada constantemente.
Son dos tablas que conformar Maestro - Detalle de las cuales la tabla
maestro va a contener un aproximado de 200,000 registros anuales y el
detalle va a contener algo de 30 lineas promedio por cada linea en la
cabecera esto nos da una aproximado de 6,000,000 registro en esta tabla de
detalle.

Estuve pensando generar un primary Key por dos campos en las dos tablas
que seria Año+NroTransaccion (Char 4 + char(6)) y a la vez estos serian
sus campos relacionables pero, lei tambien un articulo en portalsql
respecto al tema de los indices naturales vs indices artificiales donde
comentaban que tener un campo entero como primary key seria mucho mas
optimo que hacerlo mediante los indices compuestos.

Que me recomiendan Uds. por las experiencias que tienen.

si usar un indice simple con campo entero o seguir usando los clasicos
indices compuestos???

cual Join seria mas rapido Año+nrotransaccion o Solamente
nrotransaccion???

Gracias

Dany Acosta.

Respuesta Responder a este mensaje
#4 Dany
13/08/2007 - 15:15 | Informe spam
Otra consulta mas, si deseo activar los Constraint FK de las tablas maestro - detalle con las otras
tablas relacionadas... a ese volumen de datos bajaria el rendimiento???



Dany wrote:
Amigos, estoy iniciando un proyecto en una empresa pero estoy en una
duda respecto a dos tablas de la BD que tienen alto grado de
transacionabilidad y a la vez consultada constantemente.
Son dos tablas que conformar Maestro - Detalle de las cuales la tabla
maestro va a contener un aproximado de 200,000 registros anuales y el
detalle va a contener algo de 30 lineas promedio por cada linea en la
cabecera esto nos da una aproximado de 6,000,000 registro en esta tabla
de detalle.

Estuve pensando generar un primary Key por dos campos en las dos tablas
que seria Año+NroTransaccion (Char 4 + char(6)) y a la vez estos serian
sus campos relacionables pero, lei tambien un articulo en portalsql
respecto al tema de los indices naturales vs indices artificiales donde
comentaban que tener un campo entero como primary key seria mucho mas
optimo que hacerlo mediante los indices compuestos.

Que me recomiendan Uds. por las experiencias que tienen.

si usar un indice simple con campo entero o seguir usando los clasicos
indices compuestos???

cual Join seria mas rapido Año+nrotransaccion o Solamente nrotransaccion???

Gracias

Dany Acosta.

Respuesta Responder a este mensaje
#5 Maxi
13/08/2007 - 15:19 | Informe spam
Hola, a ese nivel de registros dudo que tengas problemas con ello, antes de
hilar tan fino seguramente debas ver otras cosas (cursores, indices, etc)


Salu2

Microsoft MVP SQL Server
Culminis Speaker

"Dany" escribió en el mensaje
news:
Otra consulta mas, si deseo activar los Constraint FK de las tablas
maestro - detalle con las otras tablas relacionadas... a ese volumen de
datos bajaria el rendimiento???



Dany wrote:
Amigos, estoy iniciando un proyecto en una empresa pero estoy en una duda
respecto a dos tablas de la BD que tienen alto grado de
transacionabilidad y a la vez consultada constantemente.
Son dos tablas que conformar Maestro - Detalle de las cuales la tabla
maestro va a contener un aproximado de 200,000 registros anuales y el
detalle va a contener algo de 30 lineas promedio por cada linea en la
cabecera esto nos da una aproximado de 6,000,000 registro en esta tabla
de detalle.

Estuve pensando generar un primary Key por dos campos en las dos tablas
que seria Año+NroTransaccion (Char 4 + char(6)) y a la vez estos serian
sus campos relacionables pero, lei tambien un articulo en portalsql
respecto al tema de los indices naturales vs indices artificiales donde
comentaban que tener un campo entero como primary key seria mucho mas
optimo que hacerlo mediante los indices compuestos.

Que me recomiendan Uds. por las experiencias que tienen.

si usar un indice simple con campo entero o seguir usando los clasicos
indices compuestos???

cual Join seria mas rapido Año+nrotransaccion o Solamente
nrotransaccion???

Gracias

Dany Acosta.

Respuesta Responder a este mensaje
Ads by Google
Help Hacer una preguntaSiguiente Respuesta Tengo una respuesta
Search Busqueda sugerida