¿Deben las claves foráneas convertirse en clave principal de la tabla?

Question

Tengo una tabla (session_comments) con la siguiente estructura de campos:

student_id (foreign key to students table) 
session_id (foreign key to sessions table) 
session_subject_ID (foreign key to session_subjects table) 
user_id (foreign key to users table) 
comment_date_time 
comment 

Ahora, la combinación de student_id, session_id, y session_subject_id identificará de forma única un comentario sobre ese estudiante para esa sesión sujeto.

Dado que combinados son únicos, a pesar de que son claves foráneas, ¿existe una ventaja para mí al convertirlos en la clave primaria combinada para esa tabla?

Gracias de nuevo.

Answer 1

1. Convertirlos en la clave principal forzará la unicidad (en lugar de implicarlo).
2. La clave principal se presumiblemente estará agrupada (según dbms), lo que mejorará el rendimiento de algunas consultas.
3. Ahorra el espacio de agregar una restricción única que en algunos DBMS también crea un índice único.

Ya sea que estas tres sean la clave primaria o no, igual necesitarás algún tipo de restricción de exclusividad para garantizar que un alumno no pueda asociarse con la misma sesión y session_subject_id dos veces. Si ese escenario está permitido, entonces necesitarás expandir tu restricción de exclusividad para incluir otra columna.

No importa qué opción elija, debe tener absolutamente algún tipo de restricción de exclusividad en la tabla.

Si está debatiendo si crear una clave primaria sustituta + una restricción única en las tres columnas, diría que depende de si esta tabla tendrá tablas secundarias. Si lo hace, entonces hacer referencia a la clave sustituta será más fácil y más pequeño. Si no lo hace, entonces IMO, la clave sustituta en realidad no le da mucho y también podría usar las tres columnas como PK.

Answer 2

Realmente recomendaría que use una clave principal generada por la base de datos de su elección. Principalmente porque si modifica la estructura de esa tabla durante cualquier mantenimiento futuro, entonces corre el riesgo de que su clave única no sea única. Lo cual puede ser un problema realmente difícil de resolver. Además, tener una clave principal única hace que consultar la tabla sea mucho, mucho más sencillo.

identificadores únicos para postgres: http://www.postgresql.org/docs/8.1/interactive/datatype.html#DATATYPE-SERIAL

identificadores únicos para MySQL: http://dev.mysql.com/doc/refman/5.0/en/example-auto-increment.html

Answer 3

La única razón para hacer de ellos una clave principal compuesta sería para hacer cumplir un comentario por estudiante/Sesión/sujeto. Suponiendo que no quieras hacer eso, no crearía otra clave.

Answer 4

No. Las claves FOREIGN pueden contener valores NULL que no están permitidos en las teclas PRIMARY. Lo mejor que puede hacer es crear un índice ÚNICO a partir de las columnas.

Crea una tecla PRIMARY sobre la mesa.

Respuesta: Mi siguiente pregunta es: ¿Existe la posibilidad de superposición entre las teclas de las 4 tablas?

Estos dos crearía la misma clave compuesta de 101010101: estudiante: 1010, período de sesiones: 10, tema: 10, el usuario: 1 estudiante: 10, sesión: 1010, sujetos: 10, el usuario: 1

Solo señalo que las cuatro columnas deberían tener dominios claramente diferentes para que la superposición disminuya en la posibilidad.

Probablemente sea mejor ir con una clave primaria verdadera.

Answer 5

Depende del resto de la aplicación.
Si no va a haber claves foráneas en la tabla de comentarios (lo que parece probable), está bien.
Si necesita consultar comentarios de otra tabla, sería mejor crear un índice único con sus 3 campos, más una Autonumérico clave principal que servirá en otras tablas como la clave externa (mucho más simple y más barato que los 3 campos).

Answer 6

El debate de las claves naturales frente a las artificiales es tan antiguo como cualquier implementación de base de datos. Lea sobre pro y contra en wikipedia.

Los argumentos para las claves sustitutas se discuten fácilmente en el nivel teórico (por ejemplo, el argumento de que con claves naturales se corre el riesgo de que su PK no sea único se puede contraargumentar con la respuesta - ¡bien! Si me encuentro con esa situación es bueno que las cosas se rompan en lugar de tener claves primarias artificialmente únicas con registros duplicados para datos reales).

Otro buen argumento es que las claves artificiales son redundantes (hay otra clave única en la tabla) o que le permiten almacenar registros esencialmente no únicos.

Aún así, encontrar buenas claves naturales a veces es tan difícil que debes elegir algo artificial y tener en cuenta cuando tendrás una persona con el mismo nombre, nacida en la misma fecha (o con fecha desconocida), con otras propiedades xy que tienen el mismo valor

Además, no está tan claro qué es artificial y qué es natural. Podría decir, por ejemplo, que el SSN es natural para sus datos. Aunque es un número realmente compuesto.

En cuanto al rendimiento de las relaciones de clave múltiple, estas no son tan malas como cabría esperar, además, segmenta los índices de forma natural y con esas claves generalmente se termina con una base de datos que funciona muy bien con consultas comunes sin ningún índice adicional.

Si tiene en cuenta estos problemas en serio y si usted está tratando de construir sistemas complejos, por favor leer alguna buena literatura (C.J.Date Introducción a los sistemas de bases de datos, actualmente en 8ª edición viene a la mente)