Fragen zum Datenbankdesign einer Autogramm-Verwaltung

[ipving]

Hallo,

ich habe mehrere Fragen zum Datenbankdesign einer Autogramm-Verwaltung. Hier meine erste Frage:

Ich habe eine Tabelle autogramm. Diese enthält einen eindeutigen PK "aid" und einige Attribute, die nicht weiter aufgeschlüsselt werden müssen. Jetzt hätte ich aber gerne noch mind. drei weitere Tabellen autogramm_gekauft, autogramm_angeschrieben und autogramm_selbstgesammelt mit weiteren Informationen. Die Spalten dieser drei Tabellen unterscheiden sich aber voneinander. Ein Autogramm kann entweder nur gekauft, durch Fanpost oder selbst gesammelt sein, nie gleichzeitig, das ist klar. Meine Lösung wäre nun, dass ich in allen drei Tabellen den PK "aid" aus der Tabelle autogramm als FK übernehme. Ist das so sauber? Habe irgendwie das Gefühl, dass man das so nicht macht.
Ich bin mir unsicher und benötige Euer Expertenwissen.

Danke für Eure Hilfe.

LG

 

[dabadepdu]

Du kannst eine Tabelle nehmen und eine Eigenschaft mitführen, die den verkausweg angibt.

 

[ipving]

Das habe ich auch schon im Sinn gehabt, so wie eine 1 für Tabelle "gekauft", eine 2 für Tabelle "angeschrieben" und eine 3 für Tabelle "selbst_gesammelt "oder auch per VARCHAR. Aber wie kann ich dann mit SQL die entsprechenden Daten tabellenspezfisch ausgeben?
Oder habe ich Dich missverstanden?

 

[ipving]

Kannst Du mir eine weitere Hilfe geben?

 

[akretschmer]

postgres=# create table ipving(aid int generated always as identity primary key, a1 int, kauf text, weitere_attribute jsonb, check (kauf in('gekauft','fanpost','gesammelt')));
CREATE TABLE

 

[ukulele]

Also die Information, von wo das Autogramm stammt, könnte man in einer Spalte mit führen. Das erfordert erstmal keine weitere Tabelle. Eine weitere Tabelle (oder auch mehrere) macht nur Sinn wenn du wirklich viele Informationen hast die den Erhalt des Autogramms beschreiben aber nicht zu einander passen. Also z.B. wenn dir das Autogramm vor Ort ausgestellt wurde vielleicht Attribute wie Land,Ort,Datum,Indoor/Outdoor,Anlass und bei einem Autogramm das du auf E-Bay gekauft hast Verkäufer,Preis,Datum. Dann könnte man zwei Tabellen anlegen und maximal eine davon hat maximal einen Datensatz der 1:1 den Hauptdatensatz zugeordnet wird also mit einem Fremdschlüssel auf "aid" verweist.

Man kann sich darüber hinaus noch Gedanken machen, wie man per Regel die 1:1 Beziehung erzwingt. Das ist nicht so einfach und hängt stark vom verwendeten DBMS ab.

Aber ganz erlich, man könnte genausogut die Spalten alle an die Haupttabelle anhängen. Das ist dann nicht normalisiert, aber wenn wir nicht grade von 1 Mio Autogramme reden, wen juckt das? Man könnte sogar viel einfacher Prüfroutinen einbauen, z.B. mit CHECK-Constraints. Die können dann verhindern, das ein Autogramm sowohl bei E-Bay gekauft wie auch mehrfach direkt ausgestellt worden sein soll. Das geht über mehrere Tabellen nicht sonderlich einfach.