¿Por qué usar un int como clave principal de una tabla de búsqueda?

Quiero saber por qué debería usar un int como clave principal de la tabla de búsqueda en lugar de simplemente usar el valor de búsqueda como clave principal (que en la mayoría de los casos sería una cadena).

Entiendo que usar un nvarchar (50) en lugar de un int usaría mucho más espacio si está vinculado a una tabla con muchos registros.

Por otro lado, usar el valor de búsqueda directamente básicamente nos salvaría haciendo una unión. Me imagino que esto sería un gran ahorro si siempre se requiere la unión (estamos trabajando en una aplicación web, así que esto cuenta bastante).

¿Cuáles son las ventajas de usar una clave primaria int (específicamente para una tabla de búsqueda) además de ser "lo que hay que hacer"?

La respuesta a su pregunta es lógica, no física: el valor que busca puede cambiar por razones comerciales. Por ejemplo, si indexa a sus clientes por dirección de correo electrónico, ¿qué sucede cuando cambia una dirección de correo electrónico? Obviamente, esto no se aplicará a todas sus tablas de búsqueda, pero los beneficios de hacerlo de la misma manera en toda la aplicación es que simplifica su código. Si todo es entero → relaciones enteras internamente, está cubierto.

Simplemente lea su comentario a Sandy; quizás en este caso lo que realmente desea es una restricción de verificación , no una tabla de búsqueda / clave externa, por ejemplo:

create table icecream (flavour varchar(10))
go
alter table icecream add constraint ck_flavour check (flavour in ('Orange', 'Pista', 'Mango'))
go
insert into icecream (flavour) values ('Orange')
go
insert into icecream (flavour) values ('Vanilla')
go

Ejecute esto y obtendrá:

(1 row(s) affected)
Msg 547, Level 16, State 0, Line 1
The INSERT statement conflicted with the CHECK constraint "ck_flavour". The conflict occurred in database "GAIUSDB", table "dbo.icecream", column 'flavour'.
The statement has been terminated.

Este es un método eficiente y de alto rendimiento, pero la desventaja, por supuesto, es que agregar un nuevo sabor significa un cambio de código. Aconsejaría no hacerlo en la aplicación, porque entonces debe hacerlo en todas las aplicaciones que se conectan a esta base de datos, este es el diseño más limpio posible porque solo hay una ruta de código única para hacer la validación.

“Usar el valor de búsqueda directamente”: es un poco contradictorio con el propósito real de la tabla de búsqueda. ¿Por qué guardas una mesa así? Si no es una búsqueda.
Puede ser que haya entendido mal su pregunta. Aquí hay una definición de tabla de búsqueda de msdn

Una tabla de búsqueda se utiliza para mostrar información de una tabla basada en el valor de un campo de clave externa en otra tabla. Por ejemplo, considere una tabla de pedidos en una base de datos de ventas. Cada registro en la tabla de pedidos incluye un CustomerID que indica qué cliente realizó el pedido. CustomerID es una clave externa que apunta a un registro de cliente en la tabla Clientes. Al presentar una lista de pedidos (de la tabla de pedidos), es posible que desee mostrar el nombre real de los clientes, en lugar del CustomerID. Dado que el nombre del cliente está en la tabla de clientes, y usted está presentando datos de la tabla de pedidos, debe crear una tabla de búsqueda, que tome el valor de CustomerID en el registro de pedidos, y use ese valor para navegar por la relación y devolver más legible, nombre del cliente.

¿Puedes elobrar el propósito de tu tabla de búsqueda? ¿Se utiliza para almacenar algunos datos estáticos como los siguientes y estos registros no son una entrada de los registros de otras tablas?

Mesa de sabor

Orange  
Pista  
Mango

Si lo anterior es su situación, me gustaría recomendar no usar la tabla de búsqueda; probablemente codifique estos valores de lista en su aplicación web. De esta manera puede evitar consultas innecesarias en la base de datos.

Dado que calificó su pregunta con "específicamente para una tabla de búsqueda", la respuesta probablemente se simplifica a "ahorra espacio".

Creo que si elimina ese calificador, su pregunta se convierte en '¿Por qué usar claves sustitutas sobre claves naturales?' Escribí lo siguiente en apoyo de las claves sustitutas:

"La migración de un valor entero en lugar de una clave compuesta más amplia tiene numerosos beneficios. Proporciona una buena consistencia en todo el modelo físico, en general ahorra más espacio de lo que cuesta y reduce las E / S en comparación con la migración de claves compuestas; especialmente en un pozo- modelo normalizado. Además, simplifican la comprensión de un modelo y unen consultas ".

Esto es en gran parte por qué se ha "convertido en lo estándar". El desafortunado biproducto es que las personas arrojan una clave sustituta y no piensan cuáles son las claves candidatas ... Pero ahora nos estamos saliendo de su pregunta :)

Una de las razones por las que siempre uso es que si alguien ha escrito mal un valor en la tabla de búsqueda, digamos Oraneg en lugar de Orange, es muy fácil cambiar el valor en la tabla de búsqueda.

La tabla de búsqueda con una clave primaria de número solo requerirá que se cambie el valor en la tabla de búsqueda.

La tabla de búsqueda que utiliza los valores como clave principal deberá cambiarse en la tabla de búsqueda y en cada registro de la tabla principal donde se utilizó.

Cuando define ID, también puede garantizar la unicidad. Pero cuando toma, por ejemplo, el correo electrónico, como identificador único, transfiere la responsabilidad de unicidad al tercer lado no confiable.