Tamaño de índice demasiado grande

Hola,

Puedes utilizar DECIMAL(22, 0) que utilizará 13 bytes. Una cosa importante
es saber si siempre van a ser 22 números o pueden ser menos. Y si los
quieres ordenar a la hora de mostrarlos de forma numérica (1, 2, 10, 11,
...) o alfanumérica (1, 10, 11, 2, ...)

Además deberías ver si los mismos valores van a aparecer muchas veces. Por
ejemplo por un campo que puede tener los valores A, B y más o menos en la
misma proporción no es conveniente poner un índice.

También, una vez creado el campo puedes utilizar los asistentes para
optimización de índices utilizando las consultas que realmente vas a
ejecutar sobre ellos, y el propio sistema te hará la recomendación de tener
o no el índice.

Un saludo
Salvador Ramos

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


"SeG" escribió en el mensaje
news:
Hola a todos.
Quería plantearles una duda que tenemos, y no damos con la mejor
solución.
Tenemos una tabla bastante grande (9 millones de registros), y
trabajamos con SQL2000.

Ahora tenemos la necesidad de meter un nuevo campo, que además se
utilizará para búsquedas por tanto requiere un índice, y está
compuesto de 22 digitos numéricos.

Es un campo bastante grande como veis.

Tenemos dudas si para este campo será mejor utilizar un varchar o un
numérico, no sabemos si ésto afectará a las búsquedas

Gracias a todos !!!!

On 9 nov, 14:22, "Salvador Ramos"
wrote:

Hola,

Puedes utilizar DECIMAL(22, 0) que utilizará 13 bytes. Una cosa importante
es saber si siempre van a ser 22 números o pueden ser menos. Y si los
quieres ordenar a la hora de mostrarlos de forma numérica (1, 2, 10, 11,
...) o alfanumérica (1, 10, 11, 2, ...)

Además deberías ver si los mismos valores van a aparecer muchas veces. Por
ejemplo por un campo que puede tener los valores A, B y más o menos en la
misma proporción no es conveniente poner un índice.

También, una vez creado el campo puedes utilizar los asistentes para
optimización de índices utilizando las consultas que realmente vas a
ejecutar sobre ellos, y el propio sistema te hará la recomendación de tener
o no el índice.

Un saludo
Salvador Ramos

Gracias por tu respuesta, te especifico más información por si
cambiara tu opinión al respecto.

Te comento que siempre serán 22 dígitos fijos, ya que es una clave
tipo timestamp (no es un timestamp como tal, pero similar).
Será clave única, y al ser tipo timestamp, no coinciden los valores.
Por último, solo se utilizan para buscar, nunca para mostrar ni
ordenar.
En el fondo es un campo que se calcula a mano con unos valores, y nos
viene de otro sistema ya calculado (un host). Este host nos envía un
fichero con esas claves, donde tenemos que cruzarlas con nuestra BBDD
SQL2000 para encontrar los registros y actualizarlos.

Gracias.

Ok,

En ese caso utiliza decimal(22, 0) y crea un indice por esa columna.

Un saludo
Salvador Ramos

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


"SeG" escribió en el mensaje
news:
On 9 nov, 14:22, "Salvador Ramos"
wrote:

Hola,

Puedes utilizar DECIMAL(22, 0) que utilizará 13 bytes. Una cosa importante
es saber si siempre van a ser 22 números o pueden ser menos. Y si los
quieres ordenar a la hora de mostrarlos de forma numérica (1, 2, 10, 11,
...) o alfanumérica (1, 10, 11, 2, ...)

Además deberías ver si los mismos valores van a aparecer muchas veces. Por
ejemplo por un campo que puede tener los valores A, B y más o menos en la
misma proporción no es conveniente poner un índice.

También, una vez creado el campo puedes utilizar los asistentes para
optimización de índices utilizando las consultas que realmente vas a
ejecutar sobre ellos, y el propio sistema te hará la recomendación de
tener
o no el índice.

Un saludo
Salvador Ramos

Gracias por tu respuesta, te especifico más información por si
cambiara tu opinión al respecto.

Te comento que siempre serán 22 dígitos fijos, ya que es una clave
tipo timestamp (no es un timestamp como tal, pero similar).
Será clave única, y al ser tipo timestamp, no coinciden los valores.
Por último, solo se utilizan para buscar, nunca para mostrar ni
ordenar.
En el fondo es un campo que se calcula a mano con unos valores, y nos
viene de otro sistema ya calculado (un host). Este host nos envía un
fichero con esas claves, donde tenemos que cruzarlas con nuestra BBDD
SQL2000 para encontrar los registros y actualizarlos.

Gracias.