Definición de múltiples claves foráneas en una tabla para muchas tablas

Tengo 3 modelos:

Mensaje :

  • carné de identidad
  • título
  • cuerpo

Foto :

  • carné de identidad
  • ruta de archivo

Comentario :

  • carné de identidad
  • ID del mensaje
  • cuerpo

y tablas correspondientes en DB. Ahora, si quiero tener comentarios solo para mis publicaciones, simplemente puedo agregar la siguiente clave externa: ALTER TABLE comment ADD FOREIGN KEY (post_id) REFERENCES post (id) . Pero quiero tener comentarios para otros modelos (foto, perfil, video, etc.) y mantener todos los comentarios en una sola tabla. ¿Cómo puedo definir claves externas (definitivamente necesito FK para ORM) en tal caso?

Podrías hacer esto:

  post: * post_id (PK) * title * body photo: * photo_id (PK) * filepath comment: * comment_id (PK) * body comment_to_post * comment_id (PK) -> FK to comment.comment_id * post_id (PK) -> FK to post.post_id comment_to_photo * comment_id (PK) -> FK to comment.comment_id * photo_id (PK) -> FK to photo.photo_id 

Todavía existe la posibilidad de tener un comentario que pertenece a dos elementos diferentes. Si crees que eso sería un problema, puedo intentar mejorar el diseño.

Encuentre algo común para publicar, perfil, etc. – He utilizado Entity por falta de una mejor palabra, luego subtipo.

  • En este modelo, una entidad puede tener muchos comentarios, un comentario pertenece solo a una entidad.

texto alternativo

Si quiere saber si puede tener varias claves foráneas en una sola columna, entonces la respuesta es no, no puede.

Puede tener claves externas separadas si lo desea. Entonces puedes modificar tu tabla de comentarios así:

  comment: * comment_id (PK) * PostID (FK to Post.PostID) * PhotoID (FK to .PhotoID) * ProfileID (FK to .ProfileID) * Body 

Además, deberá asegurarse de permitir nulos en las columnas PostID, PhotoID e ProfileID en la tabla de comentarios y también establecer el valor predeterminado en nulo.

Aquí está el DDL para lograr esto:

 Create table Photo ( PhotoID int, PhotoDesc varchar(10), Primary key (PhotoID) ) Create table Post ( PostID int, PostDesc varchar(10), Primary key (PostID) ) Create table Profiles ( ProfileId int, ProfileDesc varchar(10), Primary key (ProfileId) ) Create table Comment ( CommentID int, PhotoID int, PostID int, ProfileId int, body varchar(10), Primary key (CommentID), Foreign key (PhotoID) references Photo(PhotoID), Foreign key (PostID) references Post(PostID), Foreign key (ProfileId) references Profiles(ProfileId) ) insert into Photo values (1,'Photo1') insert into Photo values (2,'Photo2') insert into Photo values (3,'Photo3') insert into Post values (11,'Post1') insert into Post values (12,'Post2') insert into Post values (13,'Post3') insert into Profiles values (111,'Profiles1') insert into Profiles values (112,'Profiles2') insert into Profiles values (113,'Profiles3') insert into Comment (CommentID,PhotoID,body) values (21,1,'comment1') insert into Comment (CommentID,PhotoID,body) values (22,3,'comment2') insert into Comment (CommentID,PostID,body) values (23,11,'comment3') insert into Comment (CommentID,PostID,body) values (24,12,'comment4') insert into Comment (CommentID,ProfileId,body) values (25,112,'comment5') insert into Comment (CommentID,ProfileId,body) values (26,113,'comment6') -- to select comments seperately for Photos, profiles and posts select * from Comment where PhotoID is not null select * from Comment where ProfileId is not null select * from Comment where PostID is not null 

En ese caso, puede agregar un campo ENUM que contendrá ‘foto’, ‘perfil’ … Será la segunda parte de la clave externa

Dado que los comentarios de las fotos no son lo mismo que los comentarios posteriores, los almacenaba en tablas relacionadas separadas. Así que habría tenido:

Enviar:

  • ID del mensaje
  • título
  • cuerpo

Publicar comentario:

  • Commentid
  • cuerpo post_id

Foto:

  • Identificación fotográfica
  • ruta de archivo

PhotoComment:

  • Commentid
  • identificación fotográfica
  • cuerpo

No es una buena práctica usar id como el nombre de su PK, hace que sea mucho más difícil hacer informes y mucho más probable que involuntariamente se una a la tabla incorrecta en una consulta compleja. Si usa tablenameID y usa constantemente el mismo nombre para Fks, entonces es más fácil ver las relaciones también.

Intereting Posts