¿Hay algún beneficio de una clave primaria que comprenda todas las columnas de la tabla?

Tengo una tabla con cuatro columnas que no son anulables, y los datos son tales que las cuatro son necesarias para distinguir un registro único. Esto significa que si tuviera que hacer una clave primaria, tendría que incluir todas las columnas. Las consultas contra la tabla casi siempre serán para retirar un solo registro, es decir, todas las columnas se filtrarán en la consulta.

Dado que será necesario buscar en cada columna, ¿tener una clave principal me beneficia (además de exigir la unicidad de los registros)?

En su caso, estos campos son clave natural .

Clave sustituta:

Las claves sustitutas son claves que no tienen un significado "comercial" y se utilizan únicamente para identificar un registro en la tabla. Dichas claves se generan en la base de datos (ejemplo: Identidad en SQL Server, Secuencia en Oracle, Secuencia / Identidad en DB2 UDB, etc.) o valores generados por el sistema (como los generados a través de una tabla en el esquema).

Clave natural:

Las claves son naturales si el atributo que representa se utiliza para la identificación independientemente del esquema de la base de datos. Lo que esto básicamente significa es que las claves son naturales si las personas las usan, por ejemplo: números de factura, ID de impuestos, número de seguro social, etc.

Claves sustitutas vs Claves naturales para clave primaria

Prefiero agregar una clave sustituta para separar la gestión del modelo de negocio y la base de datos. Otra pregunta es usar el índice agrupado y no agrupado en la clave primaria. Si cambia la tabla (tabla no estática, tiene inserciones o actualizaciones de alta intensidad), tendrá problemas con el rendimiento en caso de usar índice agrupado en una clave aumentada no monotónica.

Por lo general, se recomienda que tenga una clave sustituta en tales situaciones, por lo que las claves externas en otras tablas (y cualquier referencia de registro que pueda almacenarse externamente, como si se transportan en cadenas de consulta donde una solicitud http (s) se refiere a una de los registros) tienen algo a lo que hacer referencia que no cambiará si los datos en la fila cambian. Si haces esto, entonces esa sería tu clave principal.

Si no agrega una clave sustituta, entonces dada la forma en que describe el acceso a los datos con las cuatro columnas como clave principal no sería una desventaja. Si convierte la clave en el índice agrupado para la tabla, ayudará a tales solicitudes, ya que habrá un nivel en el árbol b en el disco para bajar y encontrar los datos de una fila determinada.

Las claves compuestas como claves primarias también se encuentran con problemas de tamaño de índice que pueden afectar el uso del disco, las velocidades de io y las copias de seguridad. Es posible que desee revisar las publicaciones de Kimberly Tripp sobre claves principales e índices agrupados aquí: http://www.sqlskills.com/BLOGS/KIMBERLY/post/The-Clustered-Index-Debate-again!.aspx

Yo también sugeriría una clave sustituta en este caso en lugar de una natural.

Si tiene una tabla que representa una relación de muchos a muchos que tiene solo 2 columnas, parece razonable.

Cf. esta pregunta SO

Pero admito, que agrego Surrogate Keys incluso en esos casos.