Ich habe dein Select ausprobiert, aber er hat nicht zu dem gewünschten Ergebnis geführt, weil er nicht anzeigt, ob alle Rassenfelle der bestimmten Rasse in der Datenbank Pferde anzeigt, also falls ich ein Pferd mit einer bestimmten Farbe noch nicht habe, sehe ich das nicht.
Gute Anmerkung und sehr gutes Beispiel warum du doch einen OUTER Join brauchst; du kannst eine oder mehrere Zeilen haben welche keine Gegenstücke in den anderen Tabellen haben.
Meine Datenbank versteht nicht, was ich ihr sagen will. Ich stehe immer nur vor einem leeren Monitor und wundere mich, was ich falsch gemacht habe und kein Ergebnis bekomme.
Es gibt die "EXPLAIN" und "ANALYZE" Befehle aber das hilft eher bei Performance-Problemen als Verständnisproblemen zwischen Mensch und Machine. Meistens gewinnt die Machine in der Sturheit
Meine Datenbanken, die ich für meine diversen Projekte benutze, sind nicht sooo umfangreich, dass man irgendwelche Verzögerungen bei den Abfragen spürt.
Das ist bei aktuellen Rechner generell sogar für grössere Datenbanken oft wahr. Allerdings gehe ich davon aus dass du tatsächlich eine saubere Lösung haben willst statt "it works", sonst hättest du nach genereller Einstiegs-Methode jede Tabelle einzeln komplett in dein Programm eingelesen und dort dann in einer while()-Konstruktion zusammenkombiniert. Zusätzlich sei gesagt dass Relationen leistungsfähig sind aber trotzdem recht kostenintensiv da MySQL über mehrere Tabellen hantieren muss. Hier ein kleiner Erklärversuch der Relationen:
Vorweg; ich bin weder Datenbank-Modellierer noch beruflich -Administrator. Die Kenntnisse kommen auch aus Selbststudium und sind vermutlich unvollständig.
Ich bevorzuge Datenbank-Design über visuelle Tools zu verwirklichen, ansonsten verliere ich mich hoffnungslos sobald die Struktur etwas komplexer wird. Für Mysql wäre das Tool der Wahl generell "MySQL Workbench":
Grafisch dargestellt wären deine Tabellen wie folgend (Ich habe mir etwas Freiheiten bei den Spaltennamen genommen und rassenfelle von der Rasse getrennt um ein "Schulbeispiel" zu haben)
Zuerst mal hat jede Tabelle natürlich einen Primary-Key "id" welcher dadurch automatisch Non-Null und Unique ist. Du kannst also jede ID nur einmal haben, aber ich könnte mehrere Zeilen mit dem gleichen Inhalt haben, deshalb sind farben.farbe und rassen.name jeweils ein UNIQUE-Index. Dann ist auf Rassenfelle noch ein UNIQUE(rassenid,farbenid)-Index welcher sicherstellt dass wir jedes Rassenfell nur einmal listen.
Alle hier dargestellten (Foreignkey) Relationen zwischen den Tabellen sind 1:n, will heissen:
- pferde-n:1->farben: Wir können n Pferde mit der gleichen Farbe haben
- pferde-n:1->rassenfelle: Wir können n Pferde mit der gleichen Rasse haben
- rassenfelle-n:1->farben: Wir können n Rassen mit der gleichen Farbe haben
- rassenfelle-n:1->rassen: Wir können n Rassenfelle mit der gleichen Rasse haben
Die Relationen garantieren:
- die jeweilige Relation muss existieren. Bei Nicht-Bestehen einer farbenid beim Anlegen eines Pferdes wird der SQL Insert verweigert
- die jeweilige "ZielID" kann "einfach so" weder geändert noch gelöscht werden solange es Abhängigkeiten gibt
- Mysql "versteht" was du willst und kann das Query intern besser anpassen.
Falls du eine Relation sehr oft brauchst (zB pferde ->rassenfelle ) kann man die Queries dazu in fiktiven SQL-Tabellen speichern, sogenannten VIEWS. Diese fiktive Tabelle kann danach über SQL-Befehle abgerufen werden, als wäre es eine normale Tabelle, nur dass die Daten sauber jeweils nur 1x existieren und faktisch getrennt sind (DRY - don't repeat yourself).
)
