¿Qué ventajas tenemos al crear una tabla de mapeo separada para dos tablas relacionales?

9

En varios CMS de código abierto, noté que hay una tabla separada para mapear dos tablas relacionales. Al igual que para las categorías y productos, hay una product_category_mappingtabla separada . Esta tabla solo tiene una clave principal y dos claves externas de las categorías y tablas de productos.

Mi pregunta es ¿cuáles son los beneficios de este diseño de base de datos en lugar de simplemente vincular las tablas directamente definiendo una clave externa en cualquiera de las tablas? ¿Es solo cuestión de conveniencia?

database-design database-development Pankaj Upadhyay
fuente

Respuestas:

7

Dicha tabla a menudo se denomina tabla de enlace o tabla de puente .

Es la forma estándar de crear una relación de muchos a muchos. Con una clave externa directa entre las dos tablas, solo puede crear una relación de uno a muchos (porque la clave primaria a la que apunta la clave externa también es una restricción única), o una relación de uno a uno (si el la clave externa en sí misma también es una restricción única).

Dependiendo de la filosofía de diseño de la base de datos, la columna de clave principal a menudo se omite, y la clave principal de la tabla de puente se compone de las dos columnas de clave externa (de todos modos, necesita una restricción única en estas columnas, entonces, ¿por qué no convertirla en la ¿Clave primaria?).

tdammers
fuente
ohh k .... Entonces, en resumen, si necesito tener una relación de muchos a muchos, uno debe seguir este enfoque, ¿verdad?
Pankaj Upadhyay
1
@PankajUpadhyay: Correcto. Las relaciones MM deben implementarse de esta manera.
NoPuerto
@PankajUpadhyay: en teoría, puedes usar otros enfoques, pero son desordenados y erróneos, así que te sugiero que nunca vayas allí.
tdammers
2
@PankajUpadhyay: Si desea crear una base de datos Normalizada, debe usar una tercera tabla como se explica. Si tienes una relación 1-M, definitivamente no quieres una tercera mesa. Si tiene un MM finito y limitado y no le importa la Normalización, puede prescindir de una tercera tabla. En general, quédese con una base de datos normalizada a menos que esté construyendo un almacén de datos o una tienda de datos (en tales casos, un esquema normalizado es discutible).
NoChance
@EmmadKareem: sí, vi eso ... Mis requisitos son uno a muchos, así que no voy a crear la tabla ... Gracias amigo
Pankaj Upadhyay
2

Esa es una manera fácil de implementar relaciones de muchos a muchos .

Considere estas dos tablas: 

category
--------
categoryID [PK]
categoryName

product
-------
productID [PK]
productName

Si agrega un categoryIDcampo a product, cada producto solo puede tener una categoría. Pero si tenemos algo product_category_mappingasí:

product_category_mapping
------------------------
mappingID [PK]
productID [FK]
categoryID [FK]

entonces podemos tener:

mappingID  productID  categoryID
--------------------------------
1          1          1
2          1          2
3          2          3
4          2          1

Por lo tanto, el producto 1 es de categoría 1 y 2 y el producto 2 es de categoría 3 y 1, por lo que muchos productos pertenecen a muchas categorías y muchas categorías tienen muchos productos.

Como escribe tdammers , esta tabla a menudo se conoce como tabla de enlaces o tabla de puentes, e incluso la he visto referida como una tabla HABTM, de HasAndBelongsToMany, que aparentemente es Ruby on Rails, habla de muchos a muchos. Y Wikipedia lo llama una tabla de unión y tiene bastantes nombres más.

Yannis
fuente
No solo habla Rails, prácticamente todos los marcos PHP que he usado se refieren a él como HABTM.
sevenseacat
@Karpie ¿Algunos ejemplos? Sé que CakePHP usa el nombre HABTM, pero comenzó como un clon de Rails.
Yannis
Soy un gran admirador de los sustitutos. Pero prefiero dejar de lado la clave sustituta adicional "mappingID" y poner un PK compuesto en "productID" y "categoryID". En mi opinión, la clave compuesta compuesta por 2 sustitutos es un sustituto por derecho propio. Nunca utilizará el "mappingID" sustituto en ninguna unión.
Lord Tydus el
@ LordTydus No escribí sobre la clave compuesta como lo hicieron los tdammers, no tenía sentido reciclar su respuesta. Pero hay usos válidos para la mappingIDclave, un escenario común es realizar un mejor seguimiento de las importaciones / exportaciones masivas donde la tabla de unión contiene muchas claves foráneas.
Yannis
2

La razón para usar una tabla de mapeo es eliminar la duplicación. Siga adelante y pruebe alguna otra técnica de mapeo. No podrá evitar la duplicación de datos sin ella.

Y eso trae una pregunta de 2cd. ¿Por qué molestarse en eliminar la duplicación? Por lo tanto, solo tiene que editar los datos 1 vez en 1 lugar. A veces hay penalizaciones de rendimiento por eliminar la duplicación. Otras veces hay AUMENTOS de rendimiento para eliminar la duplicación. Por ejemplo, es más rápido llenar una lista desplegable con valores de búsqueda normalizados, que seleccionar valores duplicados distintos en una tabla grande.

Lord Tydus
fuente