J'espère que ma description est un peu meilleure que le titre, mais fondamentalement, j'ai un problème avec une partie d'un nouveau schéma d'application et je suis coincé quelle est la solution la plus maniable et élégante dans la structure de la table.Dilemme de schéma de base de données avec des clés étrangères pointant vers plusieurs tables (arc exclusif)
structure de la table des os nus avec seulement des domaines pertinents montrant serait la suivante:
compagnie aérienne (id, nom, ...)
hôtel (id, nom, ...)
fournisseur (id, nom, ...)
événement (id, nom, ...)
eventComponent (id, nom) {par exemple traiteur, location de salle, audio/visuel ...}
eventFlight (id, eventid , compagnie aérienne, ...)
eventHotel (id, eventid, hotelid, ...)
eventSupplier (id, eventid, SupplierID, hotelid, eventcomponentid, ...)
Alors compagnie aérienne, hôtel, fournisseur sont toutes les tables de référence, et un événement est de créer avec 1 à de nombreuses relations entre ces tables de référence. Par exemple, un événement peut avoir 2 entrées de vol, 3 entrées d'autres composants et 2 entrées d'hôtel. Mais le problème est que dans la table EventSupplier, le fournisseur peut être un fournisseur ou un hôtel existant. Donc, après que l'utilisateur a construit son nouvel événement sur le front-end, j'ai besoin de stocker cela d'une manière qui ne fait pas un cauchemar pour ensuite retourner ces données plus tard. J'ai fait beaucoup de lecture sur les relations polymorphes et les arcs exclusifs et je pense que mon scénario est nettement plus le long des lignes ou une relation exclusive d'arc.
Je pensais:
CREATE TABLE eventSupplier (
id SERIE PRIMARY KEY,
eventid INT NOT NULL,
hotelid INT,
SupplierID INT,
CONTRAINTE UNIQUE (eventid, hotelid , fournisseur), - Autorisations UNIQUE NULLs
CONTRÔLE DE CONTRAINTE (hotelid N'EST PAS NUL OU fournisseur n'est PAS NUL),
FOREIG N KEY (hotelid) REFERENCES hotel (id),
CLÉ À L'ÉTRANGER (fournisseur) RÉFÉRENCES fournisseur (id)
);
Ensuite, pour la récupération de ces données, utilisez simplement une jointure externe des deux tables pour déterminer laquelle est liée.
sélectionnez e.id comme eventid, s'unir (h.name, s.name) en tant que fournisseur
de eventSupplier de
jointure externe gauche
fournisseur s sur s.id = es.supplierid
gauche jointure externe
hôtel h sur h.id = es.hotelid
où h.id n'est pas nul OU s.id est non nul
Mes autres options devaient avoir une seule clé étrangère dans la table eventSupplier avec un autre domaine pour le « type » qui semble être une solution plus difficile de récupérer des données à partir, mais il ne semble assez souple si je veux l'étendre en bas de la piste sans faire de changements de schémas. Ou alternativement stocker directement l'hotelid dans la table des fournisseurs et déclarer simplement certains fournisseurs comme étant un "hôtel" bien qu'il y ait alors des données redondantes dont je ne veux pas.
Toutes les pensées à ce sujet seraient grandement appréciées!
Vive Phil
Merci pour l'ERD Damir J'apprécie vraiment que vous preniez le temps de m'aider. Je pense que je devrais probablement clarifier un peu plus la structure de l'événement, car l'approche de regroupement ne sert vraiment à rien étant donné que chaque événement est lui-même traité en tête-à-tête. Par exemple, je pourrais ajouter une conférence qui contient tout un tas de données stockées dans la table d'événements, comme les approbateurs, le propriétaire, l'organisateur, les dates, la destination, etc., et les composants d'événement supplémentaires chaque type de composant. – Phil
Donc, cette conférence pourrait avoir 2 vols, 1 réservation d'hôtel, et la location audiovisuelle et le service de traiteur qui relèvent du fournisseur/autre. Donc la partie que j'ai de la difficulté à conceptualiser est comment je peux stocker un fournisseur comme fournisseur ou comme hôtel en tenant compte à la fois des entités très différentes et des données complètement différentes. Espérons que cela a du sens? – Phil
Peut-être que: Component = food_catering, EventSource = Hôtel –