¿Cuáles son los inconvenientes de usar una clave primaria compuesta/compuesta?

Question

¿Cuáles son los inconvenientes de usar una clave primaria compuesta/compuesta?

Answer 1

Necesita más especificidad.

Llevado demasiado lejos, puede complicar demasiado las inserciones (todas las teclas DEBEN existir) y la documentación y las lecturas combinadas podrían ser sospechosas si están incompletas.

A veces puede indicar un modelo de datos defectuoso (es una clave compuesta realmente lo que está descrito por los datos?)

No creo que hay un costo de rendimiento ... sólo puede ir muy mal con mucha facilidad .

Answer 2

Recomendaría una clave primaria generada en aquellos casos con una restricción única no nula en la clave compuesta natural.

Si utiliza la clave natural como principal, probablemente tendrá que hacer referencia a ambos valores en las referencias de clave externa para asegurarse de que está identificando el registro correcto.

Answer 3

1. podría causar más problemas para la normalización (2NF, "Tenga en cuenta que cuando una tabla 1NF no tiene claves candidatas compuestas (claves candidatas que consiste en más de un atributo), la tabla está automáticamente en 2NF")
2. Más duplicación innecesaria de datos. Si su clave compuesta consta de 3 columnas, deberá crear las mismas 3 columnas en cada tabla, donde se utilizará como clave externa.
3. Generalmente evitable con la ayuda de claves sustitutas (read about their advantages and disadvantages)
4. puedo imaginar un buen escenario para la llave de compuesto - en una tabla que representa un N: N relación, como Estudiantes - clases, y la llave en la mesa intermedia será (StudentID, ClassID). Pero si necesita almacenar más información sobre cada par (como el historial de todas las calificaciones de un alumno en una clase), probablemente le presente una clave sustituta.

Answer 4

1. cuando SE IT en un diagrama son menos legible
2. cuando lo utiliza en una consulta de unión son menos legible
3. cuando se utiliza en una llave foregein hay que añadir una de restricción de comprobación de todo el atributo tiene que ser nulo o no nulo (aunque sólo uno es nula la clave no está marcada)
4. necesitan más espacio de almacenamiento cuando usualy usarlo como clave externa
5. alguna herramienta no logra compuesta clave

Answer 5

No hay nada malo en tener una clave compuesta per se, sino una clave principal idealmente debería ser lo más pequeño posible (en términos de número de bytes necesarios). Si la clave principal es larga, esto provocará que los índices no agrupados se inflen.

Tenga en cuenta que el orden de las columnas en la clave principal es importante. La primera columna debe ser tan selectiva como sea posible, es decir, tan "única" como sea posible. Las búsquedas en la primera columna podrán buscarse, pero las búsquedas solo en la segunda columna tendrán que escanear, a menos que también haya un índice no agrupado en la segunda columna.

Answer 6

Creo que se trata de una especialización del debate de clave sintética (si se utilizan claves significativas o una clave primaria sintética arbitraria). Desciendo casi por completo en el lado clave sintético de este debate por varias razones. Estos son algunos de los más relevantes:

• usted tiene que mantener dependientes niño tablas en el extremo de una clave externa al día. Si cambia el valor de uno de los principales campos clave (lo cual puede suceder - ver abajo) tiene que cambiar de alguna manera todas las tablas dependientes donde su valor PK incluye estos campos . Esto es un poco complicado porque el cambio de valores clave se invalidar las relaciones FK con tablas secundarias por lo que puede (dependiendo sobre las opciones de validación de restricción disponibles en su plataforma) que recurrir a trucos como copiar el registro a un nuevo uno y eliminando los registros antiguos .

• En un esquema de profundidad las claves pueden obtener bastante amplio - que he visto 8 columnas vez.

• Los cambios en los valores de las claves primarias pueden ser molestos al identificar en los procesos ETL que se están descargando del sistema. El ejemplo que una vez tuve ocasión de ver era una aplicación MIS que extraía de un sistema de suscripción de seguro . En algunas ocasiones , una entrada de política sería reutilizada por el cliente, cambiando el identificador de política. Esta era una parte de la clave principal de la tabla . Cuando esto sucede, la carga de almacén no tiene conocimiento de qué era el valor anterior, por lo que no puede coincidir con con los datos nuevos. El desarrollador tuvo que buscar en los registros de auditoría para identificar el valor modificado.

La mayoría de los problemas con las claves primarias no sintéticos giran en torno a cuestiones cuando los valores de PK de los registros cambian. Las aplicaciones más útiles de valores no sintéticos son aquellas en las que se pretende utilizar un esquema de base de datos, como un M.I.S. aplicación donde los escritores de informes están usando las tablas directamente. En este caso, los valores cortos con dominios fijos, como los códigos de moneda o las fechas, pueden colocarse razonablemente directamente en la tabla para su comodidad.

Answer 7

El inconveniente principal de utilizar una clave primaria compuesta es que confundirá a los generadores de código ORM típicos.

Answer 8

Tomemos el ejemplo de una tabla con dos claves candidatas: una simple (una columna) y una compuesta (varias columnas). Su pregunta en ese contexto parece ser, "¿Qué desventaja puedo sufrir si elijo promover una clave para que sea 'primaria' y elijo la clave compuesta?"

En primer lugar, considere si realmente necesita promocionar una clave: "la existencia del PRIMARY KEY en SQL parece ser un accidente histórico de algún tipo. Según el autor Chris Date, las primeras encarnaciones de SQL no tiene alguna restricción de clave y PRIMARY KEY se agregó posteriormente a los estándares SQL. Los diseñadores del estándar obviamente tomaron el término de EF¡Codd quien lo inventó, a pesar de que la noción original de Codd había sido abandonada en ese momento! (Codd propuso originalmente que las claves foráneas sólo se deben hacer referencia a una clave - la clave principal - pero esa idea fue olvidada e ignorada, ya que fue ampliamente reconocido como una limitación sin sentido) "[fuente:. David Portas' Blog: Down with Primary Keys?

En segundo lugar, ¿qué criterios lo haría aplicar para elegir qué tecla en una tabla debe ser 'primaria'? En SQL, la elección de la clave PRIMARY KEY es arbitraria y específica del producto. En ACE/Jet (también conocido como MS Access), los dos factores principales y que a menudo compiten es si usted desea use PRIMARY KEY para favorecer la agrupación en disco o si desea que las columnas que componen la clave aparezcan en negrita en la imagen 'Relaciones' en la interfaz de usuario de MS Access; soy una minoría al pensar que la estrategia de índice supera a la bonita imagen :) SQL Server, puede especificar el índice agrupado independientemente del PRIMARY KEY y parece que no se ofrece ninguna ventaja específica del producto. La única ventaja restante parece ser el hecho de que puede omitir las columnas del PRIMARY KEY al crear una clave externa en SQL DDL, que es un comportamiento estándar de SQL-92 y de todos modos no parece tan importante para mí (tal vez otro de las cosas que agregaron al estándar porque era una característica ya muy extendida en los productos SQL?) Por lo tanto, no se trata de buscar inconvenientes; más bien, debería estar buscando ver qué ventaja, si corresponde, su producto SQL da el PRIMARY KEY. Dicho de otra manera, el único inconveniente de elegir la clave incorrecta es que puede estar perdiendo una ventaja dada.

En tercer lugar, ¿hace alusión al uso de una clave artificial/sintética/sustituta para implementar en su modelo físico una clave candidata de su modelo lógico porque le preocupa que haya penalizaciones de rendimiento si utiliza la clave natural en claves externas y mesa se une? Esa es una pregunta completamente diferente y depende en gran medida de su postura 'religiosa' sobre el tema de las claves naturales en SQL.