primaria - crear llaves compuestas sql

Clave primaria compuesta (8)

Algunas personas recomiendan que use un Id. Único global (GUID): la replicación de mezcla y la replicación transaccional con suscripciones de actualización usan columnas de identificador único para garantizar que las filas se identifiquen de forma única en varias copias de la tabla . Si el valor es globalmente único cuando se crea, entonces no necesita agregar el source_id para hacerlo único.

Aunque un uniqueid es una buena clave principal, estoy de acuerdo en que, por lo general, es mejor usar una clave diferente, natural (no necesariamente única) como su índice agrupado. Por ejemplo, si un identificador único es la PK que identifica a los empleados, es posible que desee agrupar el índice para que sea el departamento (si sus declaraciones seleccionadas generalmente recuperan a todos los empleados dentro de un departamento determinado). Si desea usar un unqiqueid como el índice agrupado, vea la función NEWSEQUENTIALID() : esto crea valores secuenciales de unidivo único, que (al ser secuencial) tienen un mejor rendimiento de agrupamiento.

Estoy trabajando en el diseño de una base de datos que se utilizará para almacenar datos que se originan a partir de varias fuentes diferentes. Las instancias que estoy almacenando tienen asignadas ID únicas por las fuentes originales. Cada instancia que almacene debe contener información sobre la fuente de la que provino, junto con la ID de la que estaba asociada.

Como ejemplo, considere la siguiente tabla que ilustra el problema:

---------------------------------------------------------------- | source_id | id_on_source | data | ---------------------------------------------------------------- | 1 | 17600 | ... | | 1 | 17601 | ... | | 2 | 1 | ... | | 3 | 1 | ... | ----------------------------------------------------------------

Tenga en cuenta que si bien el id_on_source es único para cada fuente, es posible encontrar el mismo id_on_source para diferentes fuentes.

Tengo una comprensión decente de las bases de datos relacionales, pero estoy lejos de ser un experto o incluso un usuario experimentado. El problema al que me enfrento con este diseño es lo que debo usar como clave principal. Los datos parecen dictar el uso de una clave primaria compuesta de (source_id, id_on_source) . Después de una pequeña búsqueda en Google encontré algunos debates acalorados sobre los pros y los contras de las claves primarias compuestas, sin embargo, me dejó un poco confundido.

La tabla tendrá una relación de uno a muchos con otras tablas y, por lo tanto, se hará referencia a ellas en las claves externas de otras tablas.

No estoy atado a un RDBMS específico y no estoy seguro de si es importante para el argumento, pero digamos que prefiero trabajar con SQLite y MySQL .

¿Cuáles son los pros y los contras de usar una clave externa compuesta en este caso? ¿Cual preferirías?

Casi la única vez que uso una clave primaria compuesta es cuando la parte de orden superior de la clave es la clave de otra tabla. Por ejemplo, podría crear una tabla OrderLineItem con una clave principal de OrderId + LineNumber. Dado que muchos accesos en la tabla OrderLineItem serán "order join orderlineitem using (orderid)" o alguna variación de eso, a menudo es útil. También facilita la tarea de analizar los volcados de base de datos para determinar qué elementos de línea están conectados a qué orden.

Como han señalado otros, las claves compuestas son un dolor en la mayoría de las demás circunstancias porque sus uniones tienen que involucrar todas las piezas. Es más para escribir, lo que significa un mayor potencial de errores, las consultas son más lentas, etc.

Las llaves de dos partes no son malas; Los hago bastante a menudo. Soy reacio a usar una llave de tres partes. Más de tres partes, diría que olvídalo.

En su ejemplo, sospecho que hay poco que ganar usando la clave compuesta. Solo invente un nuevo número de secuencia y deje que la fuente y la clave de fuente sean atributos ordinarios.

Creo que las claves compuestas crean un modelo de datos muy natural y descriptivo. Mi experiencia proviene de Oracle y no creo que haya problemas técnicos al crear una PK compuesta. De hecho, cualquiera que analice el diccionario de datos entenderá inmediatamente algo sobre la tabla. En su caso, sería obvio que cada source_id debe tener id_on_source único.

El uso de claves naturales a menudo crea un debate candente, pero las personas con quienes trabajo como claves naturales desde una buena perspectiva de modelo de datos.

Las claves compuestas son difíciles de manejar y lentas para unirlas. Ya que está creando una tabla de resumen, use una clave sustituta (es decir, una columna de autoincremento / identidad). Deja tus columnas naturales clave allí.

Esto también tiene muchos otros beneficios. Principalmente, si se fusiona con una empresa y tienen una de las mismas fuentes, pero las claves reutilizadas, se meterán en problemas si no está utilizando una clave sustituta.

Esta es la mejor práctica ampliamente reconocida en el almacenamiento de datos (una empresa mucho más grande que la que usted está haciendo, pero aún relevante), y por una buena razón. Los sustitutos proporcionan integridad de datos y uniones rápidas. Puede quemarse muy rápidamente con las claves naturales, así que manténgase alejado de ellas como identificador y utilícelas solo en el proceso de importación.

Me encontré con problemas al usar una gran cantidad de claves compuestas y, por lo tanto, no lo recomendaría (más adelante), también descubrí que existen beneficios en una clave independiente / sustituta (en lugar de natural) al intentar revertir los errores de los usuarios . El problema era que a través de un conjunto de relaciones, una tabla unía dos tablas donde para cada fila la parte del compuesto era la misma (esto era apropiado en la 3ra forma normal, una comparación entre dos partes de un padre). Desdupliqué esa parte de la relación compuesta en la tabla de unión (así que en lugar de parent1ID, other1ID, parent2ID, other2ID había parentID, other1ID, other2ID) pero ahora la relación no pudo actualizar los cambios a la clave principal, porque intentó para hacerlo dos veces por cada ruta y falló en el medio.

Personalmente encuentro que las claves primarias compuestas son dolorosas. Para cada tabla que desee unir a su tabla de "fuentes", deberá agregar el campo source_id y id_on_source.

Yo crearía una clave principal estándar de auto-incremento en su tabla de fuentes y agregaría un índice único en las columnas source_id e id_on_source.

Esto le permite agregar solo el ID de la tabla de fuentes como una clave externa en otras tablas.

En general, también he encontrado que la compatibilidad con claves primarias compuestas en muchos marcos y productos de herramientas es "parcheada" en el mejor de los casos e inexistente en otros

Si agrega una columna de ID adicional, tendrá que imponer DOS restricciones de exclusividad en lugar de una.

El uso de esa columna de ID adicional como clave foránea en otras tablas de referencia, en lugar de la clave que se presenta de forma natural, hará que tenga que hacer MÁS uniones, es decir, en todos los casos en que necesite el original soruce_ID más ID_on_source junto con los datos de La tabla de referencias.

Usted tiene el requisito comercial de que la combinación de estos dos atributos sea única. Por lo tanto, debe tener una restricción UNIQUE en esos dos atributos. Si llama a esa restricción UNIQUE "primaria" es realmente solo una preferencia, no tiene mucho impacto aparte de la documentación.

La única pregunta es si luego agrega una columna adicional y la marca UNIQUE . La única razón por la que puedo ver eso es el rendimiento, que es una razón legítima.

Personalmente, no me gusta el enfoque de convertir cada base de datos en esencialmente un gráfico, en el que las columnas generadas son esencialmente punteros y solo se está desplazando de una a otra. Creo que eso desecha toda la grandeza de un sistema relacional. Si da un paso atrás y piensa en ello, está introduciendo un montón de columnas que no tienen ningún significado para su negocio. Usted puede estar interesado en mi blog relacionado .