¿Debo usar claves primarias de varias columnas o agregar una nueva columna?

13

El diseño actual de mi base de datos hace uso de una clave primaria de varias columnas para usar los datos existentes (que de todos modos serían únicos) en lugar de crear una columna adicional asignando una clave arbitraria a cada entrada. Sé que esto está permitido, pero me preguntaba si esta es una práctica que querría usar con cautela y posiblemente evitar (al igual que ir en C).

¿Cuáles son algunas de las desventajas que puedo ver en este enfoque o las razones por las que podría querer una clave de columna única?

    
pregunta Covar 07.02.2011 - 19:34

9 respuestas

8

Por lo general, cuando tiene una tabla con una clave primaria de varias columnas, es el resultado de una tabla de combinación (muchos a muchos) que se elevó para ser su propia entidad (y por lo tanto merece su propia clave principal). Hay muchos que argumentarían que cualquier tabla de unión DEBERÍA ser una entidad por defecto, pero eso es una discusión para otro día.

Veamos una relación hipotética de muchos a muchos:

Estudiante * --- * Clase

(un estudiante puede estar en varias clases, una clase puede tener varios estudiantes).

Entre esas dos tablas habrá una tabla de unión llamada StudentClass (o ClassStudent, según cómo la escribas). A veces, desea realizar un seguimiento de cosas como cuando el estudiante estaba en la clase. Así que lo agregarás a la tabla StudentClass. En este punto, StudentClass se ha convertido en una entidad única ... y se le debe dar un nombre para reconocerla como tal, por ejemplo. Inscripción.

Estudiante 1 --- * Inscripción * --- 1 clase

(un estudiante puede tener muchas inscripciones, cada inscripción es para una clase (o, por el contrario, una clase puede tener muchas inscripciones, cada inscripción es para un estudiante).

Ahora puedes consultar cosas como, ¿cuántos estudiantes se inscribieron en la clase de Química 101 el año pasado? ¿O en qué clases se matriculó el estudiante John Doe mientras asistía a la Universidad Acme? Esto fue posible sin la clave principal separada, pero una vez que tenga una clave principal para la inscripción, una consulta más fácil sería de estas inscripciones (por identificación), ¿cuántos estudiantes recibieron una calificación aprobatoria?

La determinación de si una entidad merece un PK se reduce a la cantidad de consultas (o manipulación) que realizará para esa entidad. Digamos, por ejemplo, que desea adjuntar las tareas completadas para un estudiante en una clase. El lugar lógico para adjuntar esta entidad (Asignación) estaría en la entidad de Inscripción. Darle la inscripción a su propia clave principal haría que las consultas de asignación sean más sencillas.

    
respondido por el Michael Brown 07.02.2011 - 21:51
8

Tiene sentido tener una columna de identificación separada. Cuando quiera obtener algo de la tabla de su base de datos, es más fácil hacerlo:

SELECT whatever FROM table WHERE id=13

que     SELECCIONE lo que DESDE la tabla DONDE col1 = 'val1' Y col2 = 'val2' Y col3 = 'val3'

Por ejemplo, en una aplicación web se traduce en una url que se ve así:

www.somewebsite.com/somepage.php?id=13

o como esto:

www.somewebsite.com/somepage.php?col1=val1&col2=val2&col3=val3
    
respondido por el infrared 07.02.2011 - 19:45
8

Básicamente, estás preguntando si deberías usar claves sustitutas o naturales (en su caso, suena como claves naturales compuestas ). Aquí hay un gran artículo: enlace

Prefiero las claves sustitutas porque simplifican la administración a lo largo de la vida útil de la base de datos (nunca debe preocuparse por la implicación de que las claves cambien de significado, lo que nunca debería suceder pero sí ocurre en cualquier sistema real en el que participen seres humanos). Sin embargo , si hay muchas tablas de "búsqueda" en la base de datos (es decir, tablas que son básicamente clave: pares de valores), entonces las claves sustitutas pueden resultar incómodas porque tiene que unir esas tablas en la consulta con el fin de obtener resultados significativos.

Por ejemplo, supongamos que tiene dos entidades: Dirección y País.

  • La relación es: Dirección * ----- 1 país
  • La entidad del país es básicamente una clave: par de valor (por ejemplo, EE. UU .: Estados Unidos, CA: Canadá, MX: México, etc.)
  • Para consultar esta estructura para todas las direcciones en los Estados Unidos:

select * from Address where CountryCode = 'US'

  • Para realizar la misma consulta con claves sustitutas:

select Address.* from Address join Country on Address.CountryID = Country.ID where Country.Code = 'US'

Me siento cómodo ordenando claves naturales para tablas de búsqueda y claves sustitutas para todo lo demás, si estoy bastante seguro de que las claves naturales no cambiarán con demasiada frecuencia, si es que alguna vez.

    
respondido por el Curtis Batt 07.02.2011 - 22:10
5

Depende de cómo acceda a los datos. Si realiza muchas búsquedas de claves parciales (donde selecciona registros basados en, por ejemplo, solo dos de las tres claves), entonces querrá mantener las claves de varias partes. OTOH, si tiene muchas relaciones 1: 1 con otras tablas, probablemente tenga más sentido tener una clave sustituta.

    
respondido por el TMN 07.02.2011 - 20:17
1

Me gusta tener siempre una clave primaria sustituta para cada tabla. Pero no hay muchas razones "difíciles" para hacer cumplir esto que he escuchado.

La única vez que tuve una clave natural de varias columnas que me mordió fue con ORM. De vez en cuando tendría problemas con una clave principal de varias columnas usando Linq To Entities.

    
respondido por el Mike M. 07.02.2011 - 19:42
1

Nunca digas nunca, pero unirte en 4 columnas es un dolor. Cuantas más columnas tenga con datos inteligentes, mayor será la posibilidad de que esos valores cambien. Las bases de datos se pueden configurar para mantener la integridad referencial con actualizaciones en cascada.

Siempre puedes crear otro índice para manejar los valores únicos.

El rendimiento es probablemente despreciable en la mayoría de los casos, pero puede probar sus consultas con y sin la clave de ruteo.

    
respondido por el JeffO 07.02.2011 - 21:03
0

Me resulta difícil encontrar una buena razón para ordenar una clave separada, pero como usted dijo, mucha gente lo puso.

No encuentro esto de ayuda (especialmente con el almacenamiento) cuando se trata de tablas de hechos / detalles. Ejemplo canónico: una tabla de datos de ventas con (customer_key, store_key, product_key) con cantidad no tiene mucho sentido tener una clave de nivel de registro.

    
respondido por el Jé Queue 07.02.2011 - 20:06
0

Hacer que PK sea un autoincremento int reduce la molestia si encuentra que su clave compuesta puede en realidad tener duplicados.

    
respondido por el Paul Nathan 07.02.2011 - 20:54
0

Hay una buena discusión desde 2002 en Pregúntale a Tom . Es específico de Oracle, pero la discusión más amplia es relevante independientemente de la base de datos que esté utilizando.

    
respondido por el Rhys Gibson 07.02.2011 - 22:07

Lea otras preguntas en las etiquetas