SQL: ¿A clave principal o no a clave principal?

Question

Tengo una tabla con conjuntos de configuraciones para usuarios, tiene las siguientes columnas:

UserID INT
Set VARCHAR(50)
Key VARCHAR(50)
Value NVARCHAR(MAX)
TimeStamp DATETIME

UserID junto con Set y Key son únicos. Por lo tanto, un usuario específico no puede tener dos de las mismas claves en un conjunto particular de configuraciones. La configuración se recupera por conjunto, por lo que si un usuario solicita una determinada clave de un determinado conjunto, se descarga todo el conjunto, de modo que la próxima vez que se necesite una clave del mismo conjunto, no tiene que ir a la base de datos .

¿Debería crear una clave primaria en las tres columnas (ID de usuario, conjunto y clave) o debería crear un campo adicional que tenga una clave primaria (por ejemplo, un entero de incremento automático llamado SettingID, mala idea, supongo), o no crear una clave principal y simplemente crear un índice único?

----- ACTUALIZACIÓN -----

Solo para aclarar las cosas: este es un final de la tabla de líneas, de todos modos no está unido. UserID es un FK para la tabla Usuarios. Set no es un FK. Es más o menos una tabla auxiliar para mi GUI. Solo como ejemplo: los usuarios obtienen la primera vez que visitan partes del sitio web, un globo de ayuda, que pueden cerrar si lo desean. Una vez que lo eliminen, agregaré alguna configuración al " GettingStarted " conjunto que indicará que el globo de ayuda X ha sido deshabilitado. La próxima vez que el usuario acceda a la misma página, la configuración indicará que el globo de ayuda X ya no debería mostrarse.

Answer 1

  

¿Debo crear una clave principal en las tres columnas (userid, set y key)

Haz este.

El uso de la clave primaria sustituta dará como resultado una columna adicional que no se utilizará para otros fines.

Crear un ÍNDICE ÚNICO junto con la clave primaria sustituta es lo mismo que crear una PRIMARY KEY no agrupada, y dará como resultado una búsqueda adicional de KEY que es peor para el rendimiento.

Crear un ÍNDICE ÚNICO sin una PRIMARY KEY dará como resultado una tabla HEAP-organized que necesitará una búsqueda adicional de RID para acceder a los valores: tampoco muy bueno.

Answer 2

Tener claves compuestas únicas no es una buena idea.

Tener datos relevantes para el negocio como clave principal también puede causarle problemas. Por ejemplo, si necesita cambiar el valor. Si en la aplicación no es posible cambiar el valor, podría ser en el futuro o debe cambiarse en un script de actualización.

Es mejor crear una clave sustituta, un número automático que no tenga ningún significado comercial.

Editar después de su actualización:

En este caso, puede pensar en tener conceptualmente sin clave primaria , y hacer que estas tres columnas sean la clave primaria de una clave única compuesta (para que sea cambiable).

Answer 3

¿Cuántas llaves y conjuntos tienes? ¿Deben ser varchar (50) o pueden apuntar a una tabla de búsqueda? Si puede convertir este conjunto y clave en SetId y KeyId, puede crear su clave principal en los 3 valores enteros que serán mucho más rápidos.

Answer 4

Probablemente intentaría asegurarme de que UserID fuera un identificador único, en lugar de tener duplicados de UserID en todo el código. Las claves compuestas tienden a ser confusas más adelante en la vida de su código.

Supongo que este es un campo de búsqueda para valores de configuración de algún tipo, por lo que probablemente podría ir con la clave compuesta si este es el caso. Los datos ya están ahí. Puede garantizar su singularidad utilizando la clave primaria. Si cambia de opinión y luego decide que no es apropiado para usted, puede agregar fácilmente un SettingId y hacer que la clave compuesta original sea un índice único.

Answer 5

Crear una clave principal separada. No importa cómo cambie la lógica de negocios, qué nuevas reglas tendrán que aplicarse a su campo Key VARCHAR (50): tener una clave principal lo hará completamente independiente de la lógica de negocios.

Answer 6

En mi experiencia, todo depende de cuántas tablas usarán esta tabla como información FK. ¿Desea 3 columnas adicionales en sus otras tablas solo para transferir un FK?

Personalmente, crearía otra columna FK y pondría una restricción única sobre las otras tres columnas. Esto hace que las claves externas de esta tabla sean mucho más fáciles de tragar.

Answer 7

No soy un defensor de las claves compuestas, pero en este caso como un final de la tabla de líneas, podría tener sentido. Sin embargo, si permite valores nulos en cualquiera de estos tres campos porque uno o más de los valores no se conocen en el momento de la inserción, puede haber dificultades y un índice único podría ser mejor.

Answer 8

Mejor tener ID de usuario como newid de 32 bits () o identificador único porque UserID como int da una pista al usuario de la probable ID de usuario. Esto también resolverá su problema de clave compuesta.