Fremdschlüssel in mehrere Tabellen

Hallo.

Ich habe mich extra hier angemeldet, weil ich eine Frage habe, zu der ich keine Antwort finde. Ich habe schon ausgiebig gegoogelt, aber da scheitert es leider daran, dass ich nicht genau weiß, wie ich meine Frage formulieren soll.

Deshalb hoffe ich, dass ihr mir helfen könnt.



Mein Problem:

Ich möchte ein Datenbankschema bauen.

In der DB gibt es eine Tabelle "View".

Jeder dieser "Views" kann entweder einen "Blog", eine "Galerie" oder ein "Formular" enthalten (später evtl. noch mehr verschiedene Objekte).

Wie sieht die sauberste Lösung aus, hierfür ein DB-Schema zu erstellen?

Ich habe zwar gesehen, dass ein Feld z.B. in "Views" per FK auf mehrere andere Tabellen verweisen kann, weiß aber nicht, wie ich dann genau spezifiziere, welche Tabelle nun das Zeil ist.

Es gibt zwar die Möglichkeit so einen unschönen "Pseydo-FK" zu bauen mit 2 Feldern in "views", wobei ein Feld angibt auf welche Tabelle es sich bezieht und das zweite dann, welche ID in der Tabelle gemeint ist, aber ich kann mir nicht vorstellen, dass es da keine "elegantere" Variante gibt.
Zudem sind das ja dann keine korrekt definierten FKs.

Die Struktur, dass jede dieser Blogs, Galerien, etc. eine eigene Tabelle hat sollte erhalten bleiben und die Verwendung von Views auch.

Ich bin nicht auf der Suche nach einer Notlösung, sondern der eleganten Art und Weise ein solches Problem zu lösen, da ich diesesProblem schon öfter hatte.



Ich hoffe, dass ihr eine bessere Idee habe oder mir verraten könnt, ob es dafür Konstrukte gibt, die ich noch nicht kenne.

Vielen Dank schonmal vorab für die Hilfe!

Viele Grüße
Xile3

 

Du hast recht die Formulierung ist etwas "wirr" Wiso nennst du eine Tabelle "View"? - Ist das nicht etwas verwirrend?

So wie ich dich verstehe gibt es für jede dieser Entitäten eine Tabelle die diese abbildet: Blog, Galerie, Formular, etc.
Eine weitere Tabelle hat für jedes Objekt (Datensatz in einer der oben genannten Tabellen) einen eigenen Eintrag und verweisst mit einem Fremdschlüssel auf jeweils ein Objekt.

Ohne jetzt den Sinn dieser Verweisstabelle zu kennen würde ich es so abbilden wie bei dir schon erwähnt: Eine Spalte für den Fremdschlüssel, eine Spalte hält den Namen der Zieltabelle (oder eine vergleichbare Unterscheidung). Das geht aber auch nur, wenn jeder Datensatz maximal auf ein Objekt zeigt. Wenn das gegeben ist scheint mir das durchaus die beste Variante zu sein.

 

Hey ukulele,

zur Erklärung, es handelt sich um eine Homepage, wobei die Seiten aus Templates bestehen.

Jedes Template bietet Platz um verschiedene "AddOns" einzubinden, wie Beispielsweise Blog, Galerie, etc...

Diese vorgemerkten Plätze habe ich "Views" genannt.

In dieser Tabelle soll nun definiert sein, was genau dann an dieser Stelle eingebunden wird.

Wie bereits geschrieben, finde ich diese Lösung mit den "Pseydo-FKs" nicht gerade schön und denke mir, dass es da bestimmt ne bessere Lösung gibt.

Im ERM würde das in etwa so aussehen:



Ich möchte aber nicht für jedes mögliche Objekt einen FK in "Views", sondern nur einen FK in "Views", der dann je nach Fall auf die entsprechende "Unter-Tabelle" verweist.

Da es ja immer nur ein Objekt pro View geben kann, wären dann bei 20 möglichen Objekten immer 19 Attribute leer, was ich unnötig finde.


PS: Hat sonst vielleicht noch jemand einen anderen Vorschlag?

 

So habe ich mir das auch gedacht, allerdings: Eine Tabelle würde ich nicht View nennen, weil es ja auch Views in der Datenbank geben kann. Das verwirrt etwas, möglich ist es natürlich.

Du kannst einen FK in Views machen (z.B. FK Template) und einen Template Typ dazu. Deine Homepage liest den Typ aus und wählt den FK aus der jeweiligen Tabelle. Das bringt dir Vor- und Nachteile:

+
Du hast keine "leeren" Spalten (Wobei hier der Datenbank die Optimierung obliegt. Wo die Daten wie effektiv gespeichert werden regelt das DBMS. Eine Schlüsselspalte mit NULL nimmt nicht wirklich "Platz" weg. Wie das genau funktioniert kann ich auch nicht erklären aber man kann das nicht mit einer leeren Excel Spalte vergleichen die möglicherweise Speicherplatz und Geschwindigkeit kostet. In einer Datenbank kann ich den Geschwindkeitsunterschied nicht einschätzen.)

+
Aus meiner Sicht das Hauptargument für ein solches Modell: Das System kann um Templatetypen erweitert werden, ohne das die View Tabelle dazu verändert werden muss. Das nutzt z.B. unser DMS.

-
Durch die Typ Spalte musst du effektiv mehr Information speichern und auslesen. Eigentlich steigt also dein Aufwand.

-
Du kannst keinen Fremdschlüssel als Constraint in der Datenbank erstellen, zumindest ist mir kein Weg bekannt. Das ist nicht notwendig und wird häufig durch die Anwendung gemacht aber kann auch nützlich sein.

Im Prinzip ist das Thema glaube ich zu theoretisch, die Unterschiede im Platzbedarf und bei der Geschwindigkeit werden nicht messbar sein. Die Handhabung ist ausschlaggebend.