Advanced SQL - Einstiegstutorial 3 - View

1. Die Abschnitte

• Vorwort
• Stored Procedure
• View
• Subselect Teil 1
• Subselect Teil 2
• Subselect Teil 3

2. Obacht!

Wie ich der Theorie schon sagte, kann es schon mal zu richtigen Performanceproblemen führen wenn man mit Views arbeitet. Denn da gehen alle Indizes über den Jordan. Und in unserem Beispiel mit einem Online-Browsergame kann das bei exzessiver Nutzung dazu führen, dass unser Server unter der Last abraucht.

Ich mache das hier auch nur, um euch ein paar Vorteile von Views zu zeigen. Ob ihr später selber damit arbeitet, sei euch überlassen. Und überlegt euch genau, ob ihr diese Dinger wirklich einsetzen wollt!

3. Der View

Oder heißt es nun "das View"? Ach ist unsere Sprache kompliziert. Egal, konzentrieren wir uns auf das Wesentliche. Da wir davon ausgehen, dass in unserem späteren Browsergame extrem oft eine Übersicht von Gilden verlangt wird, wollen wir nicht immer und immer wieder einen Wolf bei einer Abfrage tippen, sondern kapseln das in besagtem View.

Wichtig!

Damit man einen View möglichst flexibel einsetzen kann, muss man sich vorher überlegen, welche Spalten man zurückgibt. Zu den Details komme ich gleich. Aber! Warum nimmt man nicht einfach alle? Weil es schlechter Stil ist. Und man in den seltensten Fällen tatsächlich alle Spalten benötigt.

4. Der Code

DROP VIEW IF EXISTS gildenuebersicht;
CREATE VIEW gildenuebersicht AS
  SELECT 
    g.id AS gid,
    g.name AS gilde,
    g.einnahmen,
    m.id AS mid,
    m.name AS mitglied,
    c.gold,
    w.wesen,
    s.stufe
  FROM
    gilde g
  LEFT JOIN
    mitglied m ON m.gilde = g.id 
  INNER JOIN
    charakter c ON c.id = m.charakter
  INNER JOIN
    stufe s ON s.id = c.stufe
  INNER JOIN
    wesen w ON w.id = c.wesen
  ORDER BY g.name ASC, c.gold DESC, s.stufe DESC;

Diese SQL-Abfrage solltet ihr mittlerweile im Schlaf verstehen. Wer damit immer noch Probleme hat, sollte mal mit dem eigentlichen Query ab SELECT herumspielen, bis er/sie weiß, um was es da geht.

4. Die Nutzung

Jetzt wird es kompliziert. Dieser View ist nur ein Gerüst, das man (fast) beliebig manipulieren kann. Ein SELECT * FROM gildenuebersicht liefert alle Spalten, die im View definiert wurden. Aber was ist mit Einschränkungen? Nun da gibt es ein paar Besonderheiten.

Grundsätzliches

Sobald man hier mit einem SELECT ... FROM gildenuebersicht arbeitet und zusätzlich die Ausgabe manipulieren möchte, so müssen die entsprechenden Spalten im View selber(!) bekannt sein. Das bedeutet, dass man doppelte Spaltennamen mit AS eindeutig auszeichnet. In diesem Fall also geht es um g.id, g.name, m.id und m.name.

Außerdem müssen alle Spalten, mit denen man arbeiten möchte, innerhalb des SELECT ... FROM aufgeführt werden. Ein paar Beispiele dazu.

WHERE

Sucht man nach den Infos zu einer bestimmten Gilde, so muss man den AS-Namen im View benutzen! Das hier also funktioniert

SELECT * FROM gildenuebersicht WHERE gid = 1

während ihr bei so was eine Fehlermeldung à al unknown column ... in where clause bekommt.

SELECT * FROM gildenuebersicht WHERE g.id = 1;
SELECT * FROM gildenuebersicht WHERE id = 1;

ORDER BY

Damit kann man die im View vorgegebene Sortierung "überschreiben". Auch hier muss man auf die Namen von AS zugreifen. Ansonsten haut es euch dieselbe Meldung wie beim WHERE-Beispiel um die Ohren.

SELECT * FROM gildenuebersicht ORDER BY gid, mid;

SELECT

Möchte man nicht alle Spalten des Views zurückbekommen sondern nur ganz bestimmte, so ist das auch kein Problem. So lange man sich an die Sache mit dem AS hält.

SELECT gid, gilde, mitglied FROM gildenuebersicht;

5. Fazit

Alles in allem wären Views eine echt tolle Sache, da man mit ihnen sehr flexibel SQL-Statements aufbauen kann. Leider gibt es da noch die Sache mit den Indizes, die das Zeitliche segnen. Sollte man dieses Manko mal beseitigen (Hallo ihr theoretischen Informatiker, helft uns!), so könnte man sie meiner Meinung nach sehr gut einsetzen.

zurück zum vorherigen Abschnitt weiter zum nächsten Abschnitt