PureBoard

Einfach gesagt, ich habe Galaxien, Sonnensysteme und Planeten. Alle drei Objekte haben jeweils eigene Tabellen und eine eindeutige ID und einen Fremdschlüssel zu ihrem Elternelement (damit man weiß, wo etwas hingehört).

Wenn ich jetzt einfach einen Planeten vor der Nase habe und einfach nur den Namen der Galaxie wissen will, in der er sich befindet, dann muss ich erstmal das Sonnensystem nachschlagen um darin die ID für die Galaxie zu ermitteln und dann kann ich erst mit einer finalen Abfrage den Namen holen.

Mir scheint das so, als wären das zwei Abfragen eindeutig zu viel. Das ist doch unzumutbar. Hat jemand eine Idee wie ich das löse ohne das Datenbankmodell oder seine Normalisierung zu "zerstören"?

Ich könnte in das Tupel vom Planeten einfach auch noch einen Fremdschlüssel von der Galaxie reinhauen. Datenbankunterricht war das letzte mal vor einem Jahr, ich weiß nicht warum, aber ich bekomme bei der Idee ein ungutes Gefühl, das kann vielleicht einfach sein, aber nicht unbedingt richtig.

solle mit INNER JOIN gehen:
PseudoCode:
Zumindest habe ich damals so ähnlich von einem Beitrag, das Forum ermittelt (also über Beitrag->Thema->Forum)

vllt musst du ach zwei mal INNER JOIN machen, ohne AND ... sollte ach gehen ...

Mh, so ein Join verringert die Datenbanklast schon um einiges, keine schlechte Idee, danke.

Mir ist gerade in den Sinn gekommen die aktuelle Galaxie und System ID einfach in einer Variable in JavaScript (was ich ohnehin benutze) zu speichern (gerade erst gelesen, mit HTML und MySQL bin ich ganz vorne dabei, aber JavaScript habe ich all die Jahre links liegen gelassen). Oder am besten gleich das ganze Objekt. Aber irgendwas sagt mir diesbezüglich auch wieder irgendwie ist das auch nicht die sichere Lösung.

Seit dem neuen MySQL gehen auch verschachtelte SELECTs das wäre wohl die "einfachste" methode, wenn auch nicht die aller schnellste:

Hallo,

du kannst dir auch einfach ein VIEW basteln, dass genau das für dich übernimmt, also von Planeten-ID auf Galaxien-ID mappt. So ein VIEW ist nichts anderes als ein SELECT mit allem drum und dran und liefert dir sozusagen eine neue virtuelle Tabelle, die sich aus anderen zusammensetzt. Der Datenbank-Server kann solche VIEWS schon vorberechnen und somit diese spezielle Anfrage optimieren.
Ich habe das bei meinem letzten Projekt dafür verwendet um aus einer Tabelle, die Postleitzahlen ihren Geo-Koordinaten zuordnet, eine neue Tabelle macht, die aus zwei Postleitzahlen ihre Entfernung berechnet.

Das mit dem Inner Join ist schon so ganz richtig. Soweit ich weiß ist jedoch jeder Join einzeln anzugeben und auch das auszugebende Feld mit Tabellenname anzusprechen, weshalb es dann lauten müsste: Bei so simplen Konstrukten geht's auch einfacher: Verschachtelte Selects bedarf diese einfache Abfrage noch überhaupt nicht und Views bieten sich nur an, wenn diese Abfrage sehr häufig (wirklich sehr sehr häufig) benötigt wird. Weitaus sinnvoller ist das Indizieren der angesprochenen ID-Felder.

@SirMatti74

ein " FROM TablePlaneten, TableSystem, TableGalaxie"
bedeutet doch aber in MySQL das erst alle drei tabellen miteinander Kombiniert werden, und dann die Abfrage durchgegangen wird.
Würde bei 10 Planeten/System , 10 Systemen/Galaxie und 10 Galaxien eine Länge von
Planeten(10*10*10) * Systeme(10*10) * Galaxien(10) = 1'000'000
Einträgen haben.
Was sehr unoptimiert ist!

Die Sache mit INNER JOIN sollte immer bevorzugt werden, weil dort "nacheinander" die Tabellen kombiniert werden.
Erst TablePlaneten mit TableSystem wo die SystemID gleich ist.
und diese dann mit TableGalaxie wo die GalaxieID gleich ist
und dann auf die PlanetenID untersucht.
Mit den Zahlen oben würde aus dem ersten INNER JOIN 1000*100 = 100'000 Einträge kommen und mit ON 100 ergeben
und mit dem Galaxien dann diese 100*10 = 1'000 Einträge ergeben welche dann erst abgefragt werden!
Wodurch es also nur 101'000 Abfragen gibt.

Danke für die Antworten.