sql-server - tipos - llave primaria varchar
¿Me penalizará SQL Server 2005 por usar un nvarchar(50) como clave principal, en lugar de un número entero? (5)
¿Por qué UNICODE? por ejemplo, si traduje una palabra en inglés a los caracteres Han chinos, ¿se considerarían duplicados?
¿Por qué variable? El ancho fijo es una buena característica física de una llave.
¿Por qué 50 caracteres? Eso es mucha manipulación para los usuarios (estoy de acuerdo en que "una ID int para una clave realmente es información irrelevante" y creo que las llamadas ''claves sustitutas'' nunca deberían estar expuestas a los usuarios finales, por cierto).
Además, para mí, NVARCHAR(50) es un poco ''olfato'': ¿un predeterminado de Microsoft, un puerto directo de MS Access, quizás? Esto no significa que no hayas considerado y considerado la clave, por supuesto, solo una de esas cosas para revisar.
Oh, espera: querías decir PRIMARY KEY, ¿verdad? Suponiendo que utilice explícitamente su índice agrupado único (por tabla), la designación AFAIK PRIMARY KEY no tiene implicaciones físicas en el aterrizaje de SQL Server. Por supuesto, todas las claves candidatas deben estar cubiertas por restricciones NOT NULL UNIQUE; la que elija para promover a la tecla PRIMARIO es arbitraria.
Estoy considerando modificar algunas tablas para usar nvarchar (50) como clave principal en lugar de una clave primaria int. Usar una ID int para una clave realmente es información irrelevante, es la cadena que me interesa. ¿Qué tipo de golpe de rendimiento ocurrirá, o dónde investigas esto? Aparte de cortar y probar que es.
Considere usar una clave sustituta (una clave primaria int) como clave principal / clave de índice agrupado. El problema con el uso de un nvarchar (50) como clave principal / clave de índice agrupado es que su tabla estará ordenada por esa clave, lo que significa que es probable que se fragmente mucho, y que cualquier otro índice tendrá la carga de hacer referencia a este pesado Clave primaria.
Otro problema es que presumiblemente necesita unirse a otras tablas por este tipo de valor, que es una operación más costosa a medida que crece el tamaño de la clave.
Creo que hay muy pocas situaciones en las que una clave primaria nvarchar (50) tenga sentido.
En general, las claves primarias deben ser un sustituto A MENOS que tenga una pequeña clave inmutable natural. Podría decirse que SSN, por ejemplo, podría considerarse una llave inmutable natural.
Para el rendimiento, normalmente pregunto lo siguiente:
¿Cuántas filas? 1,000 o 1,000,000 o 10,000,000 ??
¿En qué servidor está sentado? (memoria, espacio de disco)
Lo perfilaría y luego vería. Normalmente, para mí, el cuello de botella no es la base de datos, es un código mal escrito, mal implementado, etc., etc.
Has llegado a una de las principales "guerras santas" del diseño de bases de datos. El debate al que te estás refiriendo es el argumento de "sustitución vs. clave natural" que ha estado rugiendo mientras haya habido RDBMS (por lo que yo sé).
El debate esencialmente se reduce a si se debe usar una clave representativa (sustituto, por ejemplo, una columna de IDENTIDAD) versus el uso de los datos reales que describen de manera exclusiva un registro (clave natural).
Diré que no hay una respuesta "correcta". Las medidas de rendimiento son un artefacto de la plataforma y deben evaluarse mediante experimentación, pero es probable que el rendimiento no sea la principal preocupación.
Lo que considero que es el argumento principal para las claves sustitutas es la inmutabilidad de las claves primarias. Si elige usar una clave natural, renuncia a la opción de alterar esa clave una vez establecida. También abandonas la posibilidad de que pueda volverse no única en algún momento en el futuro. Por esas razones, típicamente (no siempre) uso claves sustitutivas para la mayoría de mis tablas.
Sin embargo, como mencioné, hay un debate muy antiguo lleno de discusiones sobre estrategias de indexación y adhesión de forma normal para que se lea si así lo desea.
Yo buscaría Google "sustituto vs. claves naturales". Aquí hay algunos enlaces para que comiences:
Ingeniería de Sistemas y RDBMS
Espero que esto ayude.
Para quemar definitivamente todos los argumentos propuestos por los líderes de la solución de clave natural ( cf sustituto vs guerra de clave natural ), y para abreviar, debo decir que las claves sustitutas SIEMPRE funcionan, mientras que las claves naturales tienen una tenacidad suelta para liderar a los problemas y la frustración, generalmente en momentos inesperados.
No digo que sean LA solución óptima para cada situación, pero para evitar perder el tiempo (y el de los demás) pensando en los parámetros adecuados para la mejor clave natural al crear una tabla, simplemente elija un sustituto, y listo. Y si su tabla parece tener una clave natural adecuada, simplemente agréguela como un campo con un índice (¿único?).
Y para que sea más fácil para los desarrolladores, siempre tenga su primer campo como clave principal, el segundo es la clave supuesta / pseudo natural. Tu tabla debería verse así:
Tbl_whatever
id_whatever, unique identifier, primary key
code_whatever, nvarchar(your favorite length), indexed
.....
Donde id_ es el prefijo de la clave principal, y code_ se usa para el campo indizado "natural"