Creacion de Indices en tabla Sql | SQL Server Performance Forums

SQL Server Performance Forum – Threads Archive

Creacion de Indices en tabla Sql

Saludos a Todos
Soy nuevo en este forum y quisiera hacer una consulta Tengo una tabla en sql q consta de 5 campos q deben de ser unicos
entonces los puse como claves primarias.Hasta el momento no tengo muchas dificultades
en mis select pq la cantidad de data todavia no es considerable, pero va a agrandar
en este mes de febrero ya que van a actualizar toda la data del año pasado.
Este manejo q le doy al indice primario es correcto o deberia
de crear un campo de id con la concatenacion de estos campos y crear oros indices
Cual de las soluciones me daria mejor performance para mis consultas
ya que estoy creando una Base de Datos similar y de entrada quisiera hacer lo correcto
Ademas ( bueno dispulpen lo pregunton) cual es la diferencia de crear indices idx de un
campo o concatenando campos y de ponerles cluster.
Gracias de antemano.
Lo mejor para la creación de índices es ejecutar cada consulta con el Analizador de Consultas y analizar el plan de ejecución. Si no tienes experiencia en analizar planes de ejecución, entonces deberías correr el Index Tunig Wizard (con la consulta en el Analizador) y crear los índices que te sugiera. El crear índices de un campo o varios depende de las necesidades. Una consulta puede necesitar índices de un campo o de varios.
Si la tabla es de mucha consulta y pocos inserts, no hay problema con los índices de muchos campos, pero si es de mucho inserts, entonces conviene que los índices tengan pocos campos y no muchos. Por tabla solamente se puede tener un solo índice cluster. Los índices cluster implican el ordenamiento físico de la tabla por el o los campos que lo contienen. En cambio los no cluster son punteros a la tabla por los campos que lo forman. De allí que es conveniente que los cluster tengan pocos campos 2 o 3 a lo sumo, ya que cada insert implica el reordenamiento de la tabla. Cosa que no ocurre con los no cluster. Espero haber sido de ayuda, Luis Martin
Moderator
SQL-Server-Performance.com One of the symptoms of an approaching nervous breakdown is the belief that one’s work is terribly important
Bertrand Russell
All postings are provided “AS IS” with no warranties for accuracy.
Una pregunta si yo hiciera una id como pk
cual seria lo recomendable generar un campo con la
concatenacion de todos los campos qu son unicos este seria un char de 50 caracteres o generar un id con valor autoincremental o numerico.
Y los otros campos que son unicos generarlos como una idx compuesto con
caracteristica de Unique y no cluster. Muy aparte que sea lo mas optimo para mi consulta yo deberia usar este estandard para todas mis tablas q contienen una pk compuesta de mas de 2 campos
Depende de la aplicación. Si por ejemplo, una tabla tiene el código de cliente por el cual accedes a ella para todo propósito, entonces podrías hacer un índice cluster con ese campo. Los índices non cluster conteniendo varios campos, los tendrás que agregar de acuerdo a las necesidades de cada consulta. Puede ser que una tabla tenga dos campos claves, entonces el Pk también será cluster.
Ahora si una tabla tiene 7 campos claves, entonces tienes un problema de diseño, ya que crear un pk cluster o no cluster con 7 campos perjudicará la performance. Luis Martin
Moderator
SQL-Server-Performance.com One of the symptoms of an approaching nervous breakdown is the belief that one’s work is terribly important
Bertrand Russell
All postings are provided “AS IS” with no warranties for accuracy.
Explico mi caso, tengo tablas como seccion, bloque, familia, operacion, estudio
bueno, para cada seccion puego generar bloques, para cada bloque, familias y asi sucesivamente, entonces por herencia cada tabla inferior asume el id de la tabla mayor, por consiguiente en la ultima tabla tengo cenc_codi, bloq_codi, fami_codi, oper_codi y estu_codi, el primero es char(3) y lo siguientes son int, digo que el cenc_codi = 200, puede tener bloqu_codi 1, 2, 3.. (Delateros, espaldas, mangas) etc, el cenc_codi, nuevamente 1, 2, … (Puños, Espaldas ) etc , ahora si genero un estudio, por lo que se, su insert demoraria por la cantidad de campos que tiene como pk, ahora la pregunta de carlos supongo es que sucede si a estos campos los concateno y los vuelvo pk, y a las demas las genero como indicen aislados o seria mas recomendable generar un pk que sea incremental (int) cluster y los otros campos los genero como una clave simple con restriccion de unicos no cluster.
Desde mi punto de vista la concatenación no es un buen recurso.
Nunca lo he visto en la practica. Sobre el punto:
"que sucede si a estos campos los concateno y los vuelvo pk, y a las demas las genero como indicen aislados" Desde el lado del insert, los indices existen igual, tenés la clave mas los otros indices, no me parece una buena solución, en todas las busquedas tenes que concatenar.
Esos índices me suenan mas a DBFs. Incluso las columnas se ordenan diferente, concatenando vas desde la columna menos repetitiva a la más repetitiva, en SQL voy de la más repetitiva a la menos. La otra posibilidad dice:
"generar un pk que sea incremental (int) cluster y los otros campos los genero como una clave simple con restriccion de unicos no cluster." Acá tenes un indice más, que es el incremental, si vas a crear el indice con restriccion de unicos porque directamente no lo pones como PK no clustered. Yo prefiero definir las claves para poder utilizar las restricciones foraneas que son un gran recurso y al cambiar la clave en la mitad del camino perdes el control de FK. Solo es mi opinion. Saludos
]]>