SQL Erstellung, Herangehensweise

[Cyberwood]

Guten Tag,

die verschiedensten Lehrbücher erklären die Select, Update, Insert....-Anweisungen jeweils anhand von Beispielen. Der grundsätzliche Aufbau ist mir schon klar, ich habe auch schon viele Beispiele exerziert.
Wo ich aber in der Literatur nie eine Hilfe bekommen habe, ist die strukturierte Herangehensweise um ein SQL nach einer Aufgabe zu erstellen.
Ja, im Select muss ich die Ausgabeattribute, eine SUM etc. angeben, in der Where Anweisung die Menge begrenzen.
Wie gehe ich aber strukturiert vor, wenn ich z.B. aus mehreren Tabellen mit verschachtelten Inner-Joins meine Select Mengen bilden muss.
Ich muss mir das vorstellen können, was ich tue, dann verstehe ich das auch.

Könnt Ihr mir Tipps zum strukturierten Aufbau aus eurer täglichen Praxis geben?
Hat jemand das glorreiche Schema F?

Vorab vielen Dank
Uli

 

[ukulele]

Nun meist hast du eine Tabelle auf die du alle Informationen beziehst. Wenn du also Summen / Umsätze zu sagen wir Aufträgen suchst dann sind das die Aufträge. Wenn du Umsätze nach Kunden aufschlüsseln willst sind das deine Kunden.

Dann guckst du welche Tabellen du brauchst um die Information zu erhalten und joinst diese mit deiner Auftrags- oder Kundentabelle. Für den Join muss dir dann klar sein, in welcher Beziehung die Tabellen zu einander stehen.

Dann kannst du aggregieren, sortieren, etc.

 

[Cyberwood]

Hallo Ukulele,

da fängt es bei mir schon an.

Wenn ich die Infos aus 4 Tabellen brauche, von welcher Tabelle joine ich zur welchen? Von der kleineren zur größeren etc. Muss ich da auch was beachten, wenn die Performance nicht ganz unwichtig ist.
Mein Schema F ist noch nicht gefunden.

Viele Grüße
Uli

 

[ukulele]

Was ist deine Hauptinformation? Wonach gruppierst oder sortierst du?

 

[Cyberwood]

Also, in diesem Beispiel habe ich folgende Tabellenstruktur:
1. Tabelle mit den Artikeln (ID Artikel, Artikelname, Farbe, Gewicht, Lagerstandort etc.) dann Lagerstandort (ID Lager, Ort, RegalNr. etc.) dann Kundentabelle (ID, Kunde, Adresse....) dann Bestellung (ID Auftrag, Artikel, Menge, Datum...)
Gruppieren und Sortieren will ich erst mal nicht, sondern nur eine Auswertung für einen bestimmten Kunden machen. "Was hat x im Zeitraum y gekauft".

Wie gesagt, das SQL bekomme ich hin, mir geht es nur um die Vorgehensweise z.B.
1. Erforderliche Ausgabeattribute festlegen = Select ....
2. Menge eingrenzen = Where ....
3. Daten joinen

Mir ist nur meine bisherige Methode 1.2.3. etwas zu unstrukturiert.

Gibt es da keine grundsätzliche Vorgehensweise?

 

[akretschmer]

Was ist, wenn Du einen Artikel an mehr als einem Standort lagerst? Bestellung: ist auch falsch, Du brauchst eine für die Kopfdaten (wer hat wann bestellt) und eine für die Positionen.

 

[Cyberwood]

Hallo akretschmer,
die Antwort geht schon viel zu detailliert in das ER-Modell. Es ist nur ein Beispiel ohne Bezug auf Richtigkeit von 1NF, 2NF und 3NF.
Es geht auch nicht um die Vollständigkeit der Attribute im Beispiel.

Sondern:

Nur um die methodische Herangehensweise zur Erstellung eines SQL.

 

[akretschmer]

joa, das ist dann Übung ...

 

[ukulele]

1) Also erstmal FROM festlegen. Was ist meine Hauptinformation, häufig wird nach dieser sortiert oder auf diese aggregiert.

2) Dann der SELECT Teil. Was brauche ich an Informationen...

3) ...was fehlt an Informationen? Das muss ich per JOIN holen.

4) Dazu brauche ich die Beziehungen um die ON Bedingung zu schreiben.

5) Dann kann ich den SELECT Teil vervollständigen mit allem was ich brauche.

6) Per WHERE kann ich Ausschlusskriterien definieren.

7) Dann wird aggregiert etc. und / oder sortiert.

Meist fange ich mit SELECT * FROM an und joine erstmal alles zusammen. Das kann man aber nur komfortabel machen wenn die Tabelle nicht so gigantisch ist das man zwischendurch immer wieder Abfragen absetzen kann. Auch muss man einfach oft mal was verschachteln, dann spielt sich das sowieso nicht alles in diesem Rahmen ab.

 

[Cyberwood]

Hallo Ukulele,

Erst mal vielen Dank, super ! Das sind genau die gesuchten Antworten. Ich denke zu 3. kann noch viel weiter ausgeholt werden. Was aber dann Übung ist.

Übrigens, da passt auch gut noch ein Zitat aus meinem Fundus:

If you define the Problem correctly,
you almost habe the solution.
Steve Jobs


Danke!

 

[Cyberwood]

äh, have natürlich