Clave primaria compartida

Question

Supongo que esta es una pregunta semi-común, pero no puedo encontrarla en la lista de preguntas pasadas. Tengo un conjunto de tablas para productos que necesitan compartir un índice de clave principal. Suponga algo como lo siguiente:

product1_table:
    id,
    name,
    category,
    ...other fields

product2_table:
    id,
    name,
    category,
    ...other fields

product_to_category_table:
    product_id,
    category_id

Claramente, sería útil tener un índice compartido entre las dos tablas de productos. Tenga en cuenta que la idea de mantenerlos separados es porque tienen conjuntos de campos en gran medida diferentes más allá de lo básico, sin embargo, comparten una categorización común.

ACTUALIZAR:

Mucha gente ha sugerido la herencia de mesa (o Gen-Spec). Esta es una opción que soy consciente, pero dada en otros sistemas de bases de datos podría compartir una secuencia entre las tablas que esperaba que MySQL tuviera una solución similar. Asumiré que no se basa en las respuestas. Supongo que tendré que ir con la herencia de la mesa ... gracias a todos.

Answer 1

No es realmente común, no. No hay una forma nativa de compartir una clave primaria. Lo que podría hacer en tu situación es esto:

product_table
    id
    name
    category
    general_fields...

product_type1_table:
    id
    product_id
    product_type1_fields...

product_type2_table:
    id
    product_id
    product_type2_fields...

product_to_category_table:
    product_id
    category_id

Es decir, hay una tabla de productos maestros que tiene entradas para todos los productos y tiene los campos que se generalizan entre los tipos, y tablas especificadas por tipo con claves extrañas en la tabla de productos maestros, que tienen los datos específicos de tipo.

Answer 2

Un mejor diseño es colocar las columnas comunes en una tabla de productos y las columnas especiales en dos tablas separadas. Use el Product_ID como la clave principal en las tres tablas, pero en las dos tablas especiales es, además, una clave extranjera que vuelve a la tabla de productos principales.

Esto simplifica la búsqueda básica de productos de ID y nombres por categoría.

Tenga en cuenta también que su diseño permite que cada producto esté en una categoría como máximo.

Answer 3

Parece que estás buscando herencia de mesa.

Podrías usar una tabla común product con atributos comunes tanto a Product1 como a Product2, más un type atributo que podría ser "product2" o "product1"

Luego tablas product1 y product2 tendría todos sus atributos específicos y una referencia al padre mesa product.

product:
    id,
    name,
    category,
    type

product1_table:
    id,
    #product_id,
    product1_specific_fields

product2_table:
    id,
    #product_id,
    product2_specific_fields

Answer 4

Primero déjame decir que estoy de acuerdo con todo lo que han dicho Chaos, Larry y Phil.

Pero si insistes de otra manera ...

Hay dos razones para su PK compartido. Una singularidad en las dos tablas y dos para completar la integridad referencial.

No estoy seguro de qué "secuencia" presenta el soporte de las columnas Auto_Increment. Parece que hay un configuración del sistema Para definir el incremento por valor, pero nada por columna.

Lo que haría en Oracle es solo compartir la misma secuencia entre las dos tablas. Otra técnica sería establecer un valor de paso de 2 en el auto_incremento y comenzar una en 1 y la otra en 2. De cualquier manera, está generando valores únicos entre ellos.

Puede crear una tercera tabla que no tenga más que la columna PK. Esta columna también podría proporcionar el Autonumbering si no hay forma de crear un Autonumber de omisión dentro de un servidor. Luego, en cada una de sus tablas de datos, agregaría desencadenantes de crud. Un inserto en cualquiera de los datos iniciaría primero un inserto en la tabla de índice de pseudo (y devolvería la ID para su uso en la tabla local). Del mismo modo, un eliminación de la tabla local iniciaría un eliminación de la tabla de índice pseudo. Cualquier tabla infantil que deba señalar a un padre apuntando a esta tabla de índice de pseudo.

Tenga en cuenta que esto deberá ser un desencadenante por fila y reducirá la velocidad en estas tablas. Pero las tablas como el "producto" tienden a no tener una tasa muy alta de DML en primer lugar. Cualquiera que se queje del "impacto del rendimiento" es no considerando la escala.

Tenga en cuenta que esto se proporciona como una alternativa en funcionamiento y no mi recomendación como la mejor camino

Answer 5

No puedes "compartir" una clave principal.

Sin conocer todos los detalles, mi mejor consejo es combinar las tablas en una sola tabla de productos. Tener campos opcionales que están poblados para algunos productos y no para otros no es necesariamente un mal diseño.

Otra opción es tener una especie de modelo de herencia, donde tiene una sola tabla de productos, y luego dos tablas de "subtipo" de productos, que hacen referencia a la tabla de productos principales y tienen su propio conjunto especializado de campos. Consultar este modelo es más doloroso que una sola mesa en mi humilde opinión, por lo que lo veo como la opción menos deseable.

Answer 6

Tu explicación es un poco vaga pero, por mi comprensión básica, estaría tentado a hacer esto

La tabla de productos contiene campos comunes

product
-------
product_id
name
...

La tabla Product_Extra1 y la tabla Product_Extra2 contienen diferentes campos. Estas tablas se convierten en una relación uno a uno impulsada entre el producto. Producción_id y product_extra1.Product_id, etc. Haga cumplir la relación de uno a uno estableciendo el producto_id en las tablas clave extranjeras (product_extra1, etc. a Sea único utilizando una restricción única. Deberá decidir las reglas comerciales sobre cómo se poblan estos datos.

product_extra1
---------------
product_id
extra_field1
extra_field2
....

product_extra2
---------------
product_id
different_extra_field1
different_extra_field2
....

En base a lo que tiene por encima de la tabla Product_Category, es una tabla de intersección (1 a muchos, muchos a 1) que implicaría que cada producto puede estar relacionado con muchas categorías que ahora puede permanecer igual.

Answer 7

Este es otro caso de Gen-Spec.

Ver discusión anterior