4. Routinemaessig komplexe SQL-Queries implementieren

Routinemaessig komplexe SQL-Queries implementieren

  • R

    Wie gehe ich am besten bei komplexen Aufgabenstellungen zu SQL Abfragen(bzw. relationaler Algebra) am besten vor?
    Beim Programmieren in z.B. C++ habe ich sehr gute Erfahrungen mit dem top-down Ansatz gemacht, bei dem ich einfach ein bisschen sample-Code geschrieben habe und dann die dafuer benoetigten Methoden implementiert habe. Bei SQL funktioniert das bei mir nicht. Wie loest ihr komplexere Problemstellungen bzgl. relationaler Anfragesprachen?

    thx in advance

    0
  • D

    Gehts dir nur um Queries oder auch um Datenbankdesign.

    Also ich mach meine Queries immer folgendermaßen:
    - Erstmal alle betroffenen Tabellen ermitteln
    - Die Tabelle bestimmen die am besten auf die Aufgabe passt (also auf die die anderen gejoint werden)
    - Die Join arten/reihenfolge bestimmen (je nach tabellengröße datenbank art)
    - optimieren wie der join am schnellsten läuft (eventuell indexe anlegen/abfrage schachteln) / having anweisungen
    - group anweisungen
    - where anweisung
    - order/limit

    Bei Joins immer so arbeiten das möglichst schnell möglichst wenig Daten übrig bleiben. Eventuell auch manche Wheres als Having anweisungen vorziehen. (Bei manchen Datenbanken funktioniert das nicht richtig, da musst du die joins ineinander schachteln).

    Was dabei natürlich auch passieren kann ist das du mit einem normalen Query nicht auskommst und eine Procedure/Function brauchst.

    Damit komm ich eigentlich immer recht gut zum Ziel ohne mich vorher groß zu verfahren 😉

    0
  • B

    Im Prinzip auch top-down. Erst mal leg ich fest, was ich ueberhaupt will, dann hab ich schon mal das oberste SELECT. Dann schau ich was fuer Tabellen ich dazu brauche, dann hab ich das oberste FROM. Dann schreib ich erst mal die offensichtlichen Bedingungen in die WHERE-Klausel. Wenn ich dann sehe dass ich eine Unterabfrage brauche, schreib ich die wieder nach dem gleichen Prinzip. Aber was komplizierteres als Statements mit 1-2 Unterabfragestufen hab ich noch nie geschrieben. Wenn du das oft machen musst dann lohnt sichs vielleicht, bestimmte oft vorkommende Abfragen als Views auszulagern.

    0
  • R

    @Blue & DaRpH:
    Wie ihr es beschrieben habt bin ich normalerweise auch immer vorgegangen.
    Aber ich hatte meine Frage ja zu komplexen Anfragen gestellt. Um mal ein Beispiel zu geben:
    "Erstellen Sie für die Fußball-WM 2006 eine Übersicht der Vorrundenergebnisse. Gruppieren Sie nach den
    Gruppen der Vorrunde und sortieren Sie die Mannschaften absteigend bezüglich der erzielten Punkte."

    Das Schema dazu kann man hier finden: http://www-db.in.tum.de/teaching/ws0607/DBSYS/exercises/index.shtml#uebungen

    Und hier die Musterloesung(die ich nicht hingekriegt habe) :

    create view Vorrunde as
select sp.*,(select count(*)
from Tore t, Spieler s
where t.Spiel = sp.ID
and t.SpielerNr = s.SpielerNr
and ((s.Land = sp.MannschaftA
and t.Spielsituation != ’own goal’)
or (s.Land = sp.MannschaftB
and t.Spielsituation =’own goal’))) as ToreA,
(select count(*)
from Tore t, Spieler s
where t.Spiel = sp.ID
and t.SpielerNr = s.SpielerNr
and ((s.Land = sp.MannschaftB
and t.Spielsituation != ’own goal’)
or (s.Land = sp.MannschaftA
and t.Spielsituation =’own goal’))) as ToreB
from Spiel sp
where Runde like ’Group%’;

select t.Runde, t.Land, sum(t.Punkte) as PInsg
from
(select Runde, MannschaftA as Land,
(case when ToreA < ToreB then 0
when ToreA = ToreB then 1
when ToreA > ToreB then 3
end) as Punkte
from Vorrunde
union all
select Runde, MannschaftB as Land,
(case when ToreB < ToreA then 0
when ToreB = ToreA then 1
when ToreB > ToreA then 3
end) as Punkte
from Vorrunde ) t
group by t.Runde, t.Land
order by t.Runde asc, PInsg desc;

    Wie loese ich solche Anfragen systematisch?

    0
  • D

    Die ist ja noch nicht alzu komplex 🙂

    Aber wenn die Möglichkeit besteht dann eventuell nochmal in kleinere einfachere Views aufteilen und diese dann nutzen für die Abfragen. Je kleiner die einzelnen Bestandteile desto einfacher wirds. Solltest allerdings testen inwiefern die Performance darunter leidet (Wenn zu stark dann erstmal in einzelteilen entwickeln und dann wieder zusammenbauen)

    Wenn keine Views möglich dann über Funktionen/Proceduren/Temporäre Tabellen, ansonsten ist halt auf jedenfall wichtig das man den SQL Code auch so wie C++ Code zB formatiert und sich des öfteren mal ein kommentar dazu macht. Dann bekommt man mehr Übersicht. Die Formatierung aus der Musterlösung ist zB absolut schlecht.

    0
Anmelden zum Antworten