Generalisierungs-Problem

[Chiquadelli]

hallo leute!

ich habe folgendes vereinfacht dargestellt:

table obst {

integer id;

}

table banane {

integer id references obst.id;

}

table orange {

integer id references obst.id;

}

die tabelle obst ist also die generalisierte tabelle von banane und orange.

wenn ich jetzt eine relation (auch wieder ne tabelle) auf obst habe, weiß ich ja nicht welches obst das ist.. und genau das ist mein problem!

ich müsste in jeder spezialisierten tabelle extra nachschauen.. und das kann es ja wohl nicht sein.

das ganze soll in mysql realisiert werden.. soll ich mir da in der tabelle obst noch zustäzlich speichern wo die id herkommt?

-> zb mit enum('orange','banane')

was meint ihr dazu? ne wirklich schöne lösung habe ich noch nicht

danke fürs helfen!

[baba007]

deine Architektur ist unglücklich gewählt.

Man macht in der Datenbank kein Obst und zich Tabellen für jede einzelne Frucht. Wofür auch?

Man wählt Obst und Obstart

In Obst packt man sowas wie Herkunftsland ... und in Obstart, wo deine Bananen und Orangen drin sind mit zB Name, Farbe, Preis, "was auch immer"

[Chiquadelli]

lol

selbstverständlich modelliere ich keine obstsorten -> das ist nur vereinfacht dargestellt.

die tabellen orange, banane, etc.. sind von der struktur KOMPLETT unterschiedlich und sowas lässt sich auch nicht in eine tabelle knallen.

womit meine frage (s.o.) leider noch offen ist!

[baba007]

gib mal richtiges beispiel ...

generalisierung oder spezialisierung ist eher im oop umfeld bei UML zusammen und nicht in der relDB

[Chiquadelli]

gut dann in echt:

table held {

integer id references einheit.id;

varchar(30) name;

integer erfahrung;

...

}

table gruppe {

integer id references einheit.id;

varchar(30) name;

....

}

table einheit {

integer id auto_increment;

}

und ich brauche eine neue tabelle, wie:

table hat_mitgekaempft {

integer id references einheit.id;

integer kid references kampf.kid;

}

jetzt wäre es eben umständlich 2x hat_mitgekämpft tabellen zu machen für jeweils held und gruppe; später solls auch clans geben -> daher die generalisierung.

blöd ist eben, dass ich nicht genau weiß, ob eine id aus der hat_mitgekämpft tabelle ein held oder eine gruppe ist, aber es bleiben ganz einfach 2 abfragen!

... hat_mitgekaempft NATURAL JOIN held ...

... hat_mitgekaempft NATURAL JOIN gruppe ...

wodurch ich mir meine frage schon fast beantwortet habe.. durch "generalisierung" werden zwar die tabellen weniger, aber die queries bleiben gleich viele

so werde ich das jedenfalls machen, glaub ich

danke für die große hilfe und denkanstöße - vielleicht konnt ich jemanden helfen!

ich wünschte, die großen db-hersteller würden sich trotzdem mal zu o.o.-db-systemen überreden lassen. die einfachheit bringt uns viel und ihnen viele kosten