Claves Artificiales o Naturales.

Que tal Javier.

Gracias por tu comentario.

Me ha quedado claro el problema, aqui mi situacion es como
tu comentas, tengo que poner una clave que identifique al
empleado, ahora... forzosamente cuando haga una busqueda
aunque tenga una clave artificial tendre que buscar por el
Id_Empleado, que en mi caso tiene un char de 15 pues con
el paso del tiempo se va a hacer lenta la busqueda.

Saludos y gracias de antemano.

Que tal Maxi.

Gusto de saludarte.

Me podrias dar un pequeño ejemplo de como utilizas un
campo Identity junto con otro campo que tengas como clave
principal, porque de alguna manera si te ha pasado lo
mismo que yo, al momento de hacer la busqueda por un
id_empleado aunque tengas un identity este no tendra nada
que ver con ello.

Saludos

Hola Ruben:
Creo que te estas creyendo un mito urbano de SQL!!!.
Efectivamente es importante tener indices pequenos particularmente los
indices clustered. Pero, en el caso que planteas necesitarias varios
millones de empleados para que una llave 15 bytes tenga impacto. De hecho
sobre la tabla de empleados un Llave Aritificial disminuiria el
desempeno!!!.
Un ejemplo asumamos 500,000 de empleados. Una Llave Primaria de 15 Bytes
y con el resto de las columnas que ocupen 100 bytes consume unicamente 190
Kb para el mantenimiento del Indice!!!. Es una Tabla de 60.8 Mb y se indexa
en 190 Kb.
Si usas una llave artificial que sea un entero, aumentas el espacio en
disco de la Tabla (que tiene 4 bytes adicionales) 62.8 Mb pero el indice
clustered se reduce poque ahora solo ocupa 111 Kb, (aqui perdiste otra
vez!!!), si queres mantener la restriccion para que no puedan existir
empleados con numeros repetidos y para poder hacer busquedas requeriras un
indice sobre los 15 bytes ocupando 10.8 Mb!!!.
Nop, en este caso la llave foranea produce un deterioro imporante en la
tabla.
Si la tabla empleado es referenciada en muchos lugares (como
probablemente lo es) y si el uso de la llave pequena producira algunos
beneficios de desempeno que contraresten la perdida y eventualmente superen
los problemas que produce.
Mi impresion (prejucio?) es que muchos desarrolladores necesitan el ID
para simular un arreglo (array) y poder manejar conjuntos de datos con
tecnicas de programacion procedimental. Justifican los ID's en desempeno
pero en realidad lo requieren porque no han dado el salto mental hacia
conjuntos de datos. Lo triste del caso es que por tener este ID no necesitan
pensar en conjuntos de datos y siguen escribiendo procedimentalmente lo cual
los priva de muchos de los beneficios de SQL. Un circulo vicioso.
Saludos,


Javier Loria
Costa Rica
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda.




Ruben Dario escribio:

Que tal Javier.

Gracias por tu comentario.

Me ha quedado claro el problema, aqui mi situacion es como
tu comentas, tengo que poner una clave que identifique al
empleado, ahora... forzosamente cuando haga una busqueda
aunque tenga una clave artificial tendre que buscar por el
Id_Empleado, que en mi caso tiene un char de 15 pues con
el paso del tiempo se va a hacer lenta la busqueda.

Saludos y gracias de antemano.