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.¿Me perjudicará SQL Server 2005 el uso de un nvarchar (50) como clave principal, en lugar de un número entero?
Ha 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 usar los datos reales que describen de forma 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 sustitutivas 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 adherencia de forma normal para leer si así lo desea.
Buscaría "sustituto vs. llaves naturales".Aquí hay algunos enlaces para empezar:
Espero que esto ayude.
Considere el uso de 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 principales deben ser un sustituto A MENOS que tenga una pequeña llave inmutable natural. Podría decirse que SSN, por ejemplo, podría considerarse una llave inmutable natural.
Para obtener un rendimiento, que normalmente piden los siguientes:
cuántas filas? 1,000 o 1,000,000 o 10,000,000 ??
¿en qué servidor está sentado? (memoria, espacio de disco)
Lo describirí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 ...
¿Por qué UNICODE? p.ej. 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 'olor': ¿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.
Para quemar definitivamente todos los argumentos propuestos por los líderes de la solución de clave natural (cf surrogate vs natural key war), y para abreviar, debo decir que las claves sustitutas SIEMPRE funcionan, mientras que las claves naturales tienen una tendencia débil para conducir a problemas y frustraciones, generalmente en momentos inesperados.
No digo que sean LA solución óptima para cada situación, pero para evitar perder su tiempo (y el de otros) pensando en los parámetros adecuados para la mejor clave natural al crear una tabla, simplemente elija el 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. Su mesa sólo debe ser similar a lo siguiente:
Tbl_whatever
id_whatever, unique identifier, primary key
code_whatever, nvarchar(your favorite length), indexed
.....
Dónde ID_ es el prefijo de clave principal y code_ se utiliza para el campo indexado "natural"
Kim Tripp hablado de este tema en un reciente "Ejecutar como Radio "tema. http://www.runasradio.com/default.aspx?showNum=76 – Hafthor