SQL: Daten einer Tab. in Abhängigkeit einer weiteren wählen

[Jaecko]

Moin.

Ich hab ein kleines (grosses...) Problem mit einer SQL-Syntax.

Ein kleines Beispiel anhand einer fiktiven Rezeptdatenbank soll mein Problem hier verdeutlichen:

In einer Datenbank gibt es 3 Tabellen.

In Tabelle 1 sind verschiedene Rezepte eingetragen; jeweils mit Namen und ID. Beispieldaten:

1 = Hamburger
2 = Vanilleeis
3 = Bentley
4 = Schokopudding
5 = Käsespätzle

In der 2. Tabelle findet man die Zuordnung, welche Typ-ID was heisst:
1 = Hauptgericht
2 = Nachspeise
3 = Cocktail
4 = Vorspeise

In einer 3. Tabelle befindet sich nun die Zuordnung, welches Rezept nun welcher Typ ist.
1 = 1 (Hamburger = Hauptgericht)
2 = 2 (Vanilleeis = Nachspeise)
3 = 3 (Bentley = Cocktail)
4 = 2 (Schokopudding = Nachspeise)
5 = 1 (Käsespätzle = Hauptgericht)
5 = 4 (Käsespätzle = kann auch Vorspeise sein)

Es kann also ein Rezept durchaus zu mehreren Typen gehören.

Die Frage ist nun: Wie muss hierfür die SQL-Abfrage aussehen, wenn ich z.B. aus Tabelle 1 nur die Rezepte anzeigen will, die in Tabelle 3 als "Hauptgericht" markiert sind?

Geht das überhaupt ohne grösseren Aufwand bzw. mit 1 Abfrage? Jeden Datensatz einzeln raussuchen würd schon gehen, dauert aber relativ lange.
(Also aus Tabelle 3 alle Rezept-IDs raussuchen, deren Typ-ID zutrifft; danach mit diesem Array der Rezept-IDs alle Rezepte aus Tabelle 1 einzeln rauslesen)

mfG

[TheDarkRose]

Das machst du mit JOIN's. In diesem Fall dürfts ein LEFT JOIN oder INNER JOIN sein. einfach mal nach MySQL und JOIN googlen

[Jaecko]

Ahja... thx. Macht die Suche schon einfacher, wenn man konkrete Begriffe hat.

[TheDarkRose]

Kann dir im Moment leider kein Beispiel geben, bin schon länger von MySQL direkt weg. Die Datenbank spreche ich meist nur mehr über ORM's die einem die drekte Arbeit mit der Datenbank abnehmen und die Querys selbst generieren. Arbeiten tust dann mit Objekten/Klassen zur Tabelle. Solch ein ORM mach dir auch Abfragen für solche n:m Relationen einfacher.

[Jaecko]

Kein Problem. Der Begriff JOIN hilft bei der Suche schon.

SELECT r_name FROM recipes AS r INNER JOIN recipe_types_link AS l ON r.id = l.r_id INNER JOIN recipe_types AS t ON t.id = l.t_id WHERE t.id = 5 GROUP BY r_name

Soweit sollte die Syntax passen. Lt. einem SQL-Validator (http://developer.mimer.se/validator/...dex.tml#parser) ist diese auch OK ("Conforms to Core SQL-2003").
Wenn ich das Ding jedoch in Access bzw. über C# auf ne Access-DB anwenden will, erhalt ich die Meldung:

"Syntaxfehler (fehlender Operator) in Abfrageausdruck 'r.id = l.r_id INNER JOIN recipe_types AS t ON t.id = l.t_id'.

Über diese Meldung gibts schon einige Einträge bei Google; scheinbar meckert hier aber Access, dass wohl einige Klammern fehlen. Nur lässt sich nirgendwo rauslesen, nach welchem Muster Access hier die ( ) erwartet.

[linux_80]

Wenn Du sowieso Access verwendest, kannst Du die Abfrage auch selber zusammenclicken, und die Beziehungen per drag&drop zwischen den Tabellen herstellen.
Access baut dann eine funktionierende Abfrage mit ausreichend Klammern drumrum zusammen

[TheDarkRose]

Wann war Microsoft schon Standardkonform?

[ragnar]

Die Frage ist nun: Wie muss hierfür die SQL-Abfrage aussehen, wenn ich z.B. aus Tabelle 1 nur die Rezepte anzeigen will, die in Tabelle 3 als "Hauptgericht" markiert sind?

Was du sucht ist:

SELECT * FROM rezept, typname, typzuordnung
WHERE
  rezept.id=typzuordnung.rezept_id AND
  typname.id = typzuordnung.name_id;

(Das 'JOIN' ist implizit in den mehreren Tabellen des Select enthalten)

[Ls4]

ragnars Lösung solte funktionieren. Welche Art von Join und auch die Reihenfloge der Kommandos ist vor allem entscheidend wennes um Performance geht.
Am schnellsten geht es mit einer Tabelle, die alle Kombinationen enthält. Lohnt sich aber nur bei nicht allzugroßen Datenbanken, sonst wird die Datenbank unnötig groß


Viele Grüße,

Tim

[Jaecko]

Also ich hab das mit den JOINs hinbekommen.
Access verlangt hier tatsächlich nur 1 Satz Klammern um den ersten JOIN-Klotz.
Die andere Lösung ohne Join wird auch akzeptiert.

Eine Tabelle mit allen Kombinationen möcht ich hier vermeiden; einfach aus dem Grund, da man ja nie weiss, wie mächtig die Tabelle dann wird. Nicht dass dann so ne "Indextabelle" sich aufbläst, weil alles mögliche und unmögliche drinsteht.