Llaves extranjeras múltiples

Mis diseños de bases de datos han sido más bien lineales, por lo que me estoy quedando perplejo en lo que probablemente sea un problema muy fácil de resolver.Llaves extranjeras múltiples

Tengo una tabla de "POSTS", que contiene publicaciones que pueden ser secundarias de "CATEGORÍA" o de "TEMA". ¿Cuál sería la mejor manera de definir la clave externa (s) para la tabla "POSTS"?

Supongo que podría tener una columna llamada POST_CATEGORY_ID y un campo denominado "POST_TOPIC_ID, que podría ser anulable, pero esto simplemente no suena bien. Seguro que hay una solución simple que me falta!

Fuente

2009-03-24 Anonymous

Se podría hacer muchos-a-muchos entre el poste y CATEGORÍA y POST y TEMA:

POST 
---- 
ID 
Text ... 
... 

CATEGORY 
-------- 
ID 
Name 

TOPIC 
----- 
ID 
Name 

POST_CATEGORY 
------------- 
POST_ID (FK) 
CATEGORY_ID (FK) 

POST_TOPIC 
---------- 
POST_ID (FK) 
TOPIC_ID (FK)

De esta manera, un puesto se puede asociar con cualquier cantidad de categorías y temas.

Fuente

2009-03-24 00:58:31

Esto suena más extensible, al menos desde la perspectiva de una tabla intermediaria, pero ¿no sería esto simplemente tomar mis columnas anulables de la tabla POSTS y crear una nueva tabla de ellas? –

Creo que no necesitarás elementos nulables si haces esto. Solo inserta un registro en la tabla de muchos a muchos si existe la relación –

Espere un minuto: creo que ahora sigo. Entonces, en el futuro, digamos que tengo una nueva tabla llamada LIBROS que requieren POSTS hijo, ¿simplemente agrego una tabla llamada POST_BOOK con claves externas a POSTS y BOOKS? –

Creo que una declaración clave externa sólo puede referirse a una sola tabla:

FOREIGN KEY(CATEGORY_ID) REFERENCES CATEGORY(CATEGORY_ID); 
FOREIGN KEY(TOPIC_ID) REFERENCES TOPIC(TOPIC_ID);

Si estoy en lo cierto, usted tiene que tener dos claves externas, una para la tabla de categorías y otro para TEMA, y ambos necesidad ser nulo.

Fuente

2009-03-24 00:55:47 duffymo

Estás en el camino correcto con ingenio h nullable POST_CATEGORY_ID y POST_TOPIC_ID campos. Esto modelará que una publicación se relacione opcionalmente con una categoría y opcionalmente se relacione con un tema.

Si esto es exclusivo y obligatorio, deberá agregar una restricción de verificación que sea nula, pero no ambas.

Fuente

2009-03-24 00:56:32 camh

Lo que más me molesta es si algo más tarde contiene POSTS? Tendría que modificar la tabla para admitir otra columna anulable que haga referencia a la nueva tabla. No soy inmune a hacer eso, parece estar fuera de algún modo. –

La mejor manera es usar Herencia. Tendrá dos especializaciones de "Mensajes": "Posts_Category" y "Posts_Topic" Ambos tienen "post_id" (que se refiere a la tabla padre "Mensajes") y otro campo:

"category_id" ("Posts_Category")

"topic_id" ("Posts_Topic")

Si esto suena confundir vistazo a Doctrina (PHP ORM) en su documentación: http://www.doctrine-project.org/documentation/manual/1_0/en/inheritance

Fuente

2009-03-24 00:57:17

Si desea definir las claves externas en la base de datos, la solución que estás sugiriendo suena bien También sugiero escribir un código en un desencadenador para asegurarse de que ambos campos no sean nulos.

Fuente

2009-03-24 00:57:33 Linda

¿Qué tal las categorías y temas en la misma tabla

crear topics_categories mesa (número de identificación, Descripción VARCHAR2 (100), item_type char (1)); -C o T

Entonces una sola clave externa a topics_categories

Fuente

2009-03-24 00:58:29

Respuesta

Cuestiones relacionadas