'Appartient à' db meilleures pratiques de relation?

Question

Je travaille sur un site de photographie. Les photos sur le site appartiennent toujours à exactement un événement. Ma conception initiale était:

Table: Events 
ID, Title, etc 

Table: Photos 
ID, ThumbnailURL, etc 

Table: EventPhotos 
EventID, PhotoID, SortOrder 

Cela me semble naturel, mais je me rends compte de la relation qu'il décrit permet en fait une photo d'appartenir à de nombreux événements. J'ai pensé à refactorisation comme ça, qui ne permettrait une photo d'appartenir à un événement:

Table: Events 
ID, Title, etc 

Table: Photos 
ID, EventID, SortOrder, ThumbnailURL, etc 

Il me semble un peu sale/malpropre pour que les données de relation d'événement est dans la table de photo - la Le design original sépare la photo, l'événement et la relation - mais il évite une jointure, et force la relation à un «a un/appartient à» au lieu de «a beaucoup» - qu'en pensez-vous?

Answer 1

Pour un à-plusieurs, votre deuxième prise est la norme, de façon normale, correcte de le faire.

Cependant, êtes-vous entièrement que la relation plusieurs-à-plusieurs que vous avez esquissée dans votre première prise ne s'applique pas? Je ne serais pas aussi sûr, mais vous savez que votre domaine mieux que moi

EDIT:

L'OP a ajouté un commentaire;

Merci. Je ne crois vraiment pas que les photos devraient appartenir à plus d'un événement - les événements sont des séances de photos, chaque photo est par définition tirée d'un certain tournage, et la vue par événement est la seule façon de naviguer sur le site. Je suis plutôt confiant que le one-to-many est correct.

Il y a plusieurs leçons dans ce commentaire, je voulais donc éditer ceci pour souligner ces leçons.

Observation 1. Le plus important est que vous ne pouvez pas modéliser un schéma sans connaître deux choses: le vrai domaine de problème étant modélisé, et ce que notre solution exige du modèle. Ma première estimation était que les événements et les images de l'OP modélisaient l'affichage de photos lors d'événements, comme dans une galerie d'art (ou une galerie de photos sur un site web). Dans ce cas, par exemple, la galerie en ligne Ansel Adams pourrait très bien avoir des événements, dans lesquels des photos d'Ansel Adams sont montrées, intitulées «Adams 'Mature Work», «Adams's Photos of Structures», ou «Adams's Photos of Deserts». Les trois événements peuvent inclure les "Transmission Lines in the Mohave Desert", 1941 d'Adam. Puisque de nombreuses photos pourraient être montrées dans de nombreux événements, nous aurions besoin d'une structure plusieurs-à-plusieurs.

Mais l '«événement» de l'OP est une séance de photos , et clairement, comme le note l'OP, une photo est prise en une et une seule séance photo.La leçon à retenir ici est que nous ne pouvons pas modéliser (ou seulement modéliser provisoirement) jusqu'à ce que nous connaissions le domaine du problème.

Je suggère également que le nom de la table "events" soit changé, pour rendre ce minerai explicite. L'appeler "shoot" ou "photo_shoot" rend plus clair ce que nous sommes en train de modéliser.

Observation 2. Le commentaire de l'OP fournit une réponse à son objection selon laquelle un événement FK sur une photo est «désordonné». L'OP se rend compte assez astucieusement que cela "évite une jointure, et il force la relation à un" a/appartient à "au lieu de" a beaucoup ". (Éviter une jointure est un problème de mise en œuvre, la relation correcte est plus fondamentale, car c'est une question de modélisation.)

Ce qu'il devrait également réaliser est que dans notre solution, et dans le domaine du problème, il est logique de demander d'une photo, "dans quelle photo séance/événement cette photo at-elle été prise". Et c'est pourquoi il n'est pas enchevêtré: "dans quelle session prise" est une question légitime ou un attribut d'une photo, et le FK fournit la réponse à cette question.Elle signifie également que dans ce cas, le FK de la photo à l'événement ne devrait pas t être nullable: une photo doit avoir une séance photo, sinon il ne pourrait y avoir aucune photo

(Il y a quelques leçons supplémentaires ici, sur ce que cela signifie d'avoir une relation un-à-plusieurs ou un nombre-à-plusieurs, et ce que cela signifie de rendre un FK nul ou non, je vais les relier à un autre moment.)

Answer 2

Je ne peux pas dire que j'ai jamais été enclin à utiliser votre première option pour quelque chose comme ça. J'irais avec le second. Beaucoup moins de requêtes seraient utilisées. Le simple tri de votre requête par SortOrder fonctionnerait aussi bien.

Ajouté: La seule raison pour laquelle j'utiliserais le premier est si vous voulez (au moins à un certain point) faire en sorte que les photos puissent être ajoutées à plus d'un album, ce qui ne semble pas être le cas .

Answer 3

Je vote pour la deuxième prise. table

Answer 4

Ensuite, le deuxième design que vous avez est le plus propre. Avec la première conception, vous pouvez utiliser une relation «a un» entre les tables Photos et EventPhotos, mais cela n'a vraiment aucune signification pour les séparer comme ça. Si, à l'avenir, vous pensez que vous avez besoin de relations plusieurs-à-plusieurs, alors, à ce stade, changez le design en original.

Cheers, Gra.

Answer 5

N'importe comment la conception provoquera la relation un-à-plusieurs que vous obtiendriez dans la seconde était avaoid une jointure de plus. Mais après la bonne conception de DB je préférerai le premier. Vous pouvez penser de cette façon si seulement la table des photos a besoin de la relation avec d'autres tables cette fois-ci, votre eventID dans cette table n'a aucun rôle dessus.

For samll level db design i would prefer 2 but for large or medium scale i would prefer the first. 

Answer 6

Je suis d'accord avec les autres qui pointent votre deuxième option est la méthode acceptée pour réaliser un-à-plusieurs (un événement, de nombreuses photos). Un arrière-plan orienté objet vous amènerait à penser que la présence d'une colonne de clé étrangère dans la table des photos est un couplage inconfortable de deux entités distinctes. Mais du point de vue de la base de données relationnelle, c'est ainsi que cela se passe. La seule façon de préserver votre premier choix, tout en empêchant une photo d'être utilisée pour plusieurs événements, est de placer une contrainte unique sur la colonne PhotoID de EventPhotos. La relation entre EventPhotos et Photos deviendrait alors un one-to-one, ce qui est un peu inutile, mais vous obtenez un découplage des photos et des événements.

Votre choix, mais de nombreuses années de conception de bases de données relationnelles réussies plaideront toujours pour la deuxième option.