Zwei Entitäten mit namentlich gleichen Primärschlüsseln

D

deggit

Benutzer
Beiträge
7
Hallo ihr lieben,

ich habe eine kurze Verständnisfrage. Im Anhang findet ihr ein Er-Modell bei diesem gibt es zwei Entitäten mit jeweils einen namentlich gleichen Primärschlüssel. (Benutzer und Profilbilder haben beide BenutzerID und Historie und Spiel haben beide SpielID)

Das dies erlaubt? Schlechter Entwurfsstil aber geht in der Praxis???

Viele liebe Grüße und danke für eure Antworten

Deg

ER-Modell

PS: ich hoffe das mit dem Bild hat geklappt. Ich musste einen Link nehmen weil das hochladen und das Bild einfügen aus irgendwelchen Gründen nicht klappt bei mir

Ohhh, es klappt. Nur in der Vorschau sieht man nichts ;-)
 

Anhänge

  • 20180420_184601.jpg
    20180420_184601.jpg
    53,7 KB · Aufrufe: 0
  • 20180420_184601.jpg
    20180420_184601.jpg
    53,7 KB · Aufrufe: 2
  • 20180420_184601.jpg
    20180420_184601.jpg
    53,7 KB · Aufrufe: 0
  • 20180420_184601.jpg
    20180420_184601.jpg
    53,7 KB · Aufrufe: 0
Werbung:
deggit schrieb:
Im Anhang findet ihr ein Er-Modell bei diesem gibt es zwei Entitäten mit jeweils einen namentlich gleichen Primärschlüssel. (Benutzer und Profilbilder haben beide BenutzerID
Zum Vergrößern anklicken....

... probieren wir es doch mal:

Code: 
test=# create table benutzer(benutzer_id int primary key);
CREATE TABLE
test=*# create table profilbiler(benutzer_id int primary key);
CREATE TABLE
test=*#

ich sehe da jetzt weder eine Fehlermeldung noch ein Problem.
 
Meine heißen alle "pk" und, wenn es nur einen Fremdschlüssel von einer auf die andere Tabelle gibt heißt der immer "fk_<andere_tabelle>". Dadurch kann der Spaltenname natürlich in mehreren Tabellen vorkommen, ist aber auch praktisch. Läßt sich sehr intuitiv schreiben und einfach kopieren, mit ein paar Anpassungen ist das Query dann schnell wiederverwendet.
 
Werbung:
Guude

Also das zwei Tabellen die gleichen Feldnamen für die Schlüssel haben, ist erst mal nicht verwerflich.
Zu hinterfrage wäre das nur, wenn die Schlüsselfelder den gleichen Sachverhalt abbilden, die beiden Tabellen also die selben Objekte in ihren Sätzen abbilden.
In deinem Beispiel also Benutzer und Profile-Bild:
Hier könnte ein Purist darauf verweisen, dass man doch das Profile-Bild direkt in der Benutzer-Tabelle ablegen könnte.
Aber es kann aus Performancegründen geboten sein, zwei Tabellen anzulegen.
So braucht man bei einfachen Anfragen nicht das Bild mit zuladen. Erst wenn explizit das Bild verlangt wird greift man auf die andere Tabelle zu. Nebenbei verbraucht man dann auch weniger Speicherplatz, wenn nicht alle Benutzer ein Bild haben.
Moderne Datenbanken habe für solche Fälle natürlich BLOB-Felder und optimieren auch die Zugriffe. Aber manchmal ...

Wenn natürlich die Bilder-Tabelle noch einen weiteren Schlüssel hat (z.B. AB_DATUM), dann ist ist es sogar geboten, den Name des ersten Teils des Schlüssels gleich zu nennen. Die Bilder-Datei wäre dann nur eine abhängige Tabelle zur Personendatei und der Schlüssel stellt diese Abhängigkeit dar.

BTW: Vor hunderten Jahren habe ich mal folgende Beziehungsabkürzung gelernt:
"O" Owned by : Eine Tabelle gehört einer anderen Tabelle
Primarykey(s) der Untertabelle kommen in der Obertabelle als PrimaryKey vor
Man kann sich streiten, ob alle Keys der Obertabelle betroffen sein müssen.
Wenn nicht, dann wird es einer weiter oben liegende Tabelle geben, für die die Bedingung dann gilt
"R":Referenced by: Eine Tabelle referziert auf eine andere Tabelle
Ein (nicht PK) Feld ist PK in einer anderen Tabelle
"E":Extended: Eine Tabelle ist eine Erweiterung einer anderen Tabelle
Alle PrimaryKeys stimmen überein

Für eine Feld gibt es dann noch das Kürzel "K" für PrimaryKey

So kann man relativ schnell die Verhältnisse zwischen Tabellen und die Funktion von Feldern in Tabelle beschreiben/zeichnen

Gruß Ingo
 
Zurück
Oben