[0:01] Hi, hier ist Stefan. In dieser Podcast-Episode geht es ums Fachgespräch.

[0:05] Wenn du noch mehr Informationen zum Fachgespräch von mir haben willst,

[0:08] dann schau doch mal auf meiner Website vorbei, dasperfektefachgespräch.de.

[0:14] Und jetzt wünsche ich dir viel Spaß mit der Podcast-Episode.

[0:20] Herzlich willkommen zum Anwendungsentwickler-Podcast,

[0:22] dem Podcast rund um die Ausbildung zum Fachinformatiker für Anwendungsentwicklung.

[0:27] In dieser Episode geht es um häufige Fragen im Fachgespräch, und zwar SQL.

[0:32] Viel Spaß dabei!

[0:37] Hallo und herzlich willkommen zur 19. Episode des Anwendungsentwickler-Podcasts.

[0:42] Mein Name ist Stefan Macke und heute sprechen wir ein bisschen über

[0:46] ein weiteres häufiges Thema der Fragen im Fachgespräch, und zwar SQL.

[0:53] Was ist das Ganze eigentlich und was für Fragen kann man da so erwarten

[0:56] und wie sollte man sie beantworten?

[0:58] Heute setze ich mal die Reihe meiner Fragen rund um Datenbanken fort.

[1:02] Ich hatte ja schon in den letzten beiden Episoden was zu den anderen Bereichen

[1:05] der Datenbankfragen erläutert, einmal zu Datenbanken allgemein

[1:09] und dann in der letzten Folge auch insbesondere zu relationalen Datenbanken.

[1:13] Und das Ganze wäre natürlich nicht vollständig, wenn man sich auch noch SQL anschaut,

[1:16] denn SQL ist ja die Standardsprache, um mit relationalen Datenbanken zu arbeiten.

[1:21] Dementsprechend kann man auch erwarten, dass dort einige Fragen in der Prüfung zugestellt werden.

[1:25] Ihr kennt das sicherlich auch schon aus den schriftlichen Prüfungen.

[1:28] Da ist eigentlich fast in ganzheitlich 1 und 2 immer eine dicke SQL-Aufgabe drin.

[1:34] Und so ähnlich sieht es auch im Fachgespräch aus.

[1:36] SQL ist etwas, was jeder ITler können muss, übrigens auch nicht nur für Anwendungsentwickler,

[1:40] sondern jeder ITler muss das können, deswegen sehen wir es halt auch so oft in ganzheitlich 2.

[1:44] Und da kann man auch schön was zu fragen, weil es halt in allen möglichen Projekten eingesetzt wird

[1:51] und die meisten Prüflinge sollten das aus der Praxis in irgendeiner Art und Weise kennen.

[1:55] Und gerade bei Anwendungsentwicklern in vielen Abschlussprojekten wird natürlich auch SQL verwendet,

[1:59] weil tendenziell sehr viele Abschlussprojekte natürlich auch mit relationalen Datenbanken arbeiten.

[2:03] Und da ist SQL eigentlich so ein bisschen Brot und Butter, um mit den Datenbanken zu arbeiten.

[2:07] Und da kann man also davon ausgehen, dass dort in irgendeiner Weise etwas gefragt wird.

[2:11] Gerade auch, wenn man ein super gutes Projekt gemacht hat und man vielleicht auch ein bisschen nach Fragen sucht,

[2:16] wo man denn den Prüfling vielleicht noch so ein bisschen auf den Zahn fühlen könnte,

[2:21] da wird dann häufig auch was aus dem SQL-Bereich genommen, weil es halt so, ich sag mal, Grundwissen ist.

[2:25] Und da kann man gut abprüfen, ob da wirklich dann das entsprechende Know-how da ist oder eben nicht.

[2:30] Gut, dann steigen wir doch einfach mal ein in mögliche Fragen rund um SQL.

[2:34] Ich habe mir mal so ein paar rausgenommen, fangen wir mit der Einstiegsfrage an.

[2:38] Was ist denn überhaupt SQL? Was heißt das Ganze und was macht man damit?

[2:42] Also SQL steht für Structured Query Language und das ist eine Abfragesprache für relationale Datenbanken.

[2:48] Das war es eigentlich auch schon. Es gibt von der SQL einen Standard,

[2:53] der also im Prinzip in allen relationalen Datenbanksystemen, die diesem Standard folgen, angeboten werden muss.

[2:59] Das heißt, wenn ich SQL kann oder beziehungsweise diese Grundmenge an SQL-Befehlen, die standardisiert ist,

[3:04] dann kann ich also mit jeder relationalen Datenbank kommunizieren und die Werte so abfragen, wie ich sie haben möchte.

[3:10] Das ist das Schöne an SQL. Das ist wirklich ein Standard, mit dem ich also mehrere Datenbanksysteme,

[3:14] konkrete, also zum Beispiel SQL Server oder Oracle oder MySQL oder was auch immer,

[3:19] die kann ich alle damit abfragen und ich muss quasi nur eine Sprache lernen.

[3:23] Wohingegen, wenn ich mir die Programmiersprachen der Datenbanken anschaue,

[3:27] die also benutzt werden zum Beispiel für Stored Procedures,

[3:30] die sind für jedes Datenbanksystem unterschiedlich.

[3:33] Da gibt es zum Beispiel PLSQL im Bereich Oracle oder das T-SQL für Microsoft SQL Server.

[3:38] Die können ungefähr das Gleiche, aber die sind teilweise sehr unterschiedlich.

[3:42] Bei SQL ist das eben nicht der Fall.

[3:44] Da gibt es eine gewisse Grundmenge an Befehlen, die standardisiert ist und die eben mit jeder relationalen Datenbank arbeiten.

[3:50] Und das ist das Schöne daran. Das ist wirklich ein Industriestandard, sage ich mal,

[3:54] und davon gibt es in der IT jetzt, ja doch, es gibt schon ziemlich viele,

[3:58] aber nicht ganz so viele, die man schön in der Prüfung unterbringen kann.

[4:01] Zum Beispiel bei Programmiersprachen, da ist ja wirklich jede unterschiedlich

[4:04] und da kann ich jetzt also nicht bei der Abschlussprüfung voraussetzen,

[4:07] dass zum Beispiel jeder Prüfling Java kennt.

[4:10] Man könnte davon ausgehen, dass das in der Berufsschule gelehrt wird,

[4:13] aber es gilt nicht für jeden Prüfling.

[4:15] Und je nachdem, an welcher Berufsschule man ist, kriegt man das vielleicht gar nicht beigebracht,

[4:18] sondern wird vielleicht eine andere Sprache benutzt, vielleicht Python oder C Sharp oder was auch immer.

[4:22] Und da ist es also schwierig, einen gemeinsamen Standard zu definieren.

[4:25] Da muss man sich also auf die gewissen Grundmerkmale von Programmiersprachen einigen,

[4:30] zum Beispiel Algorithmen, Schleifen oder Verzweigungen und sowas, das kann man halt schön abfragen,

[4:34] aber die konkrete Syntax einer Programmiersprache wird sehr schwierig und ist auch nicht zielführend,

[4:38] weil halt jeder Prüfling gegebenenfalls eine unterschiedliche Sprache lernt.

[4:41] Bei SQL ist das anders, das ist ein Standard und den muss jeder können

[4:44] und über die Anwendungsentwickler hinaus muss das auch jeder Physikern oder jeder Informatikkaufmann

[4:49] oder auch ein IT-Systemkaufmann, weil es einfach so ein schöner und wichtiger Bestandteil auch ist,

[4:54] egal ob ich die Datenbank selber modelliere zum Beispiel als Anwendungsentwickler

[4:58] oder als Kaufmann die Daten einfach nur abfrage, weil ich herausfinden muss,

[5:02] welcher meiner Kunden den höchsten Umsatz macht.

[5:04] All das kann ich mit SQL machen und deswegen ist es auch grundsätzlich für alle IT-Berufe relevant und interessant.

[5:11] Also haben wir das geklärt, das ist SQL.

[5:14] Dann kann man sich anschauen, die SQL besteht aus mehreren verschiedenen Konstrukten,

[5:20] aus mehreren Befehlen oder Statements und die kann man etwas unterordnen in verschiedene Gruppen.

[5:25] Je nachdem, wie man das Ganze jetzt macht und wo man nachschlägt, gibt es fünf Untergruppen.

[5:30] Also ich persönlich nehme immer gerne die fünf.

[5:32] Ich habe auch einige Seiten schon gesehen, wo das dann auf drei runtergebrochen wird

[5:35] und dann die Befehle unterschiedlich einsortiert werden.

[5:38] Ich gehe jetzt einfach mal von den fünf aus, die ich jetzt im folgenden nenne.

[5:41] Man kann die Einordnung aber eben auch anders vornehmen.

[5:45] Gut, also zurück zur Frage, welche Untergruppen von SQL gibt es

[5:48] und was sind so übliche Statements, die da drin vorkommen?

[5:51] Ich merke mir das Ganze immer so ein bisschen wie anhand eines Lebenszykluses einer Datenbank.

[5:56] Stellen wir uns mal vor, es gibt noch gar keine Datenbank, da muss ich erst mal eine Datenbank anlegen.

[6:01] Und was mache ich dafür? Ja, ich lege Tabellen an.

[6:03] Das heißt, da fällt mir auch schon das erste Statement ein, create table.

[6:06] Und diese Statements zusammen mit zum Beispiel drop table oder alter table,

[6:10] die gehören zur Untergruppe der DDL, der Data Definition Language.

[6:15] Bedeutet, ich habe noch gar keine Datenbank, ich habe noch gar keine Tabellen

[6:19] und muss diese erst mal definieren und deswegen Data Definition Language.

[6:25] Also alles, was ich wirklich an der Struktur von Tabellen ändere, anlegen, löschen und eben verändern,

[6:31] solche Sachen, das gehört zur DDL dazu.

[6:35] Dann habe ich jetzt die Struktur festgelegt in meinem Lebenszyklus.

[6:38] Ich habe jetzt also leere Tabellen, ich habe die Spalten definiert und so weiter,

[6:41] aber es sind ja noch gar keine Daten in der Datenbank.

[6:44] Das wäre jetzt der nächste Schritt, den ich eigentlich durchgehen müsste.

[6:46] Ich müsste jetzt Daten in meine Datenbank ja einfügen oder ändern oder löschen.

[6:51] In unserem aktuellen Lebenszyklus allerdings erst mal einfügen, denn es gibt ja noch nichts.

[6:55] Und das sind dann die entsprechenden Insert, Update oder Delete Statements

[6:59] und die zählen dann zur Gruppe der DML, der Data Manipulation Language.

[7:04] Das heißt, wir verändern unsere Daten.

[7:07] Wir verändern nicht unsere Struktur, also die Tabellen, die bleiben unangetastet,

[7:11] sondern die Daten in diesen Tabellen werden verändert, manipuliert

[7:15] und deswegen Data Manipulation Language.

[7:18] Klassiker, wie gesagt, Insert, Update, Delete, um eben die Daten in der Datenbank einzufügen,

[7:24] zu ändern oder zu löschen.

[7:26] Wenn wir dann jetzt die Daten in der Datenbank haben, dann wollen wir natürlich auch abfragen.

[7:30] Und das ist sicherlich der größte Teil, der auch in der Praxis am häufigsten benutzt wird.

[7:35] Wir fügen eigentlich sehr selten Daten ein oder ändern sogar die Struktur der Datenbank,

[7:39] aber weitaus häufiger werden diese Daten abgefragt.

[7:42] Dafür gibt es dann eine Untergruppe, die DQL, die Data Query Language

[7:47] und dazu zählt eigentlich ein Statement, nämlich Select.

[7:50] Das ist auch das, was sicherlich in der Prüfung am häufigsten gefragt wird.

[7:53] Da kann man nämlich alle möglichen Variationen von Select Statements finden

[7:56] und da werden wir gleich auch noch ein bisschen näher darauf eingehen.

[7:59] Aber als Untergruppe haben wir eigentlich nur das Select Statement für diese DQL,

[8:02] die Data Query Language.

[8:04] Query heißt ja Abfrage und genau darum geht es.

[8:07] Wir fragen unsere Daten aus der Datenbank ab.

[8:10] Ja, das wäre es eigentlich auch schon so im Lebenszyklus.

[8:13] Datenbank anlegen, Datenbank füllen, dann wieder abfragen.

[8:15] Aber es gibt noch zwei weitere Untergruppen, die ich dann jetzt nicht mehr so ganz passen,

[8:19] denn diesen Lebenszyklus ein bisschen einbauen kann.

[8:21] Aber das muss man sich dann irgendwie zusätzlich merken.

[8:23] Zum Beispiel könnte man das einsortieren, nachdem ich die Datenbank angelegt habe,

[8:26] müsste ich vielleicht erstmal festlegen, wer denn welche Rechte auf dieser Datenbank hat.

[8:29] Und da sind wir nämlich dann gleich bei der nächsten Untergruppe,

[8:32] nämlich der DCL, der Data Control Language.

[8:35] Da geht es also darum, welcher Benutzer Zugriff auf welche Tabellen oder Spalten, Views,

[8:40] was auch immer ihr da setzen wollt, haben soll.

[8:43] Und da gibt es insbesondere zwei Statements, nämlich einmal Grant und einmal Revoke.

[8:47] Und damit kann ich die Rechte setzen.

[8:49] Ich kann zum Beispiel sagen, dass der Benutzer XY Leserechte auf eine bestimmte Tabelle hat

[8:53] oder ein anderer Benutzer darf die Tabelle auch noch ändern und so weiter und so fort.

[8:57] Und mit Grant kann ich diese Rechte setzen und mit Revoke kann ich sie wieder entziehen.

[9:03] Deswegen Data Control Language.

[9:06] Und als allerletztes haben wir dann noch die sogenannte Transaction Control Language, die TCL.

[9:12] Das sind insbesondere zwei Statements, nämlich Commit und Rollback.

[9:15] Die kann ich auch irgendwie nicht so in die anderen Gruppen einsortieren, meiner Meinung nach.

[9:20] Einige sortieren die vielleicht bei der Data Manipulation Language ein,

[9:23] weil ich damit ja steuere, ob die Daten überhaupt manipuliert werden oder nicht.

[9:27] Mit dem Commit kann ich ja sagen, so, jetzt wird die Änderung wirklich festgeschrieben,

[9:31] jetzt wird persistiert und mit dem Rollback kann ich sagen, ich nehme meine Änderung zurück.

[9:35] Also könnte man sie vielleicht auch bei der DML einsortieren.

[9:37] Ich persönlich finde diese Trennung in Transaction Control Language ganz sinnvoll.

[9:42] Deswegen ist das jetzt die fünfte Gruppe, Commit und Rollback.

[9:45] Das ist also dazu da, um eine Transaktion zu steuern.

[9:48] Ja, damit haben wir eigentlich schon alle wichtigen Statements des SQL-Standards durch.

[9:54] Wir haben natürlich jetzt nicht die Zeit und auch nicht die Möglichkeit,

[9:56] hier im Podcast zu besprechen, wie jetzt genau die Syntax aussieht.

[9:59] Das führt jetzt ein bisschen zu weit.

[10:00] Das kann man auch in einer mündlichen Prüfung ja schlecht machen.

[10:03] Also wenn das gefragt würde, in einer mündlichen Prüfung, würde ich mir denken,

[10:06] ist das wirklich noch sinnvoll?

[10:07] Also bei einem Select-Statement, wo wir gleich noch zu kommen,

[10:10] da ist das durchaus sinnvoll, weil man das wirklich quasi jeden Tag anwendet.

[10:13] Aber so aus dem Kopf runterbeten, wie so ein Insert-Statement aussieht

[10:16] oder ein Create-Table und wo die Klammer hin muss,

[10:18] also finde ich schon sehr schwierig.

[10:19] Finde ich nicht so sinnvoll für eine mündliche Prüfung.

[10:21] Vielleicht wird das gefragt.

[10:23] Okay, da müsst ihr es natürlich können.

[10:24] Da kann ich euch auch nicht sagen, das wird sicherlich nicht rankommen.

[10:26] Ihr müsst das nicht lernen.

[10:27] Das kann ich nicht tun.

[10:28] Aber ich persönlich fände es einfach ein bisschen seltsam, so etwas zu fragen.

[10:31] Das finde ich nicht sinnvoll für eine mündliche Prüfung.

[10:34] Dann kommen wir mal zu etwas abstrakteren Themen, die man auch etwas besser beschreiben kann.

[10:39] Konkrete Frage, was bedeuten Selektion und Projektion?

[10:44] Wenn ich eine Datenbank abfrage, eine Tabelle abfrage,

[10:47] dann kann ich Daten selektieren oder auch projizieren.

[10:51] Und das hört sich ganz hochtragend an, ist aber ganz einfach eigentlich.

[10:54] Die Selektion, das kennt ihr schon vom Select-Statement.

[10:57] Was selektiere ich da? Meine Zeilen.

[11:00] Also wenn ich aus meiner Tabelle nur bestimmte Zeilen auswähle,

[11:03] zum Beispiel mit einer WHERE-Bedingung,

[11:05] dann ist das eine sogenannte Selektion,

[11:07] weil ich aus der Menge an verfügbaren Datensätzen nur bestimmte rauswähle, also selektiere.

[11:13] Demgegenüber gibt es noch die Projektion.

[11:16] Die kann man allerdings auch in einem Select-Statement finden.

[11:18] Und die Projektion ist nichts anderes als die Auswahl von Spalten.

[11:21] Das heißt, wenn ich so etwas mache wie Select Name, Vorname from irgendwas,

[11:26] dann wird halt nicht der gesamte Datensatz, also alle Spalten selektiert,

[11:29] sondern nur Vorname und Nachname.

[11:31] Und damit habe ich eine Projektion gemacht.

[11:34] Das heißt, ich treffe quasi eine Auswahl meiner Spalten und nicht meiner Zeilen.

[11:39] Und diese beiden Begriffe stehen eben genau für das.

[11:42] Selektion, Auswahl von Zeilen. Projektion, Auswahl von Spalten.

[11:47] Okay, dann sind wir schon fast mittendrin.

[11:49] Wie sieht denn jetzt ein übliches Select-Statement so aus?

[11:54] Und da kann man jetzt so ein bisschen runterbeten, was man alle so gelernt hat.

[11:57] Ich kann sagen, Select Spalten from Tabellen, gegebenenfalls auch mehrere,

[12:03] where Bedingung oder Bedingungen, dann kommt ein Group By gegebenenfalls,

[12:08] wenn ich gruppieren will, anhand von bestimmten Spalten.

[12:10] Danach kommt dann ein Having, wo ich dann die Ergebnisse der Group By-Abfrage

[12:14] noch einschränken kann, wenn ich möchte.

[12:16] Und zuletzt kann ich mit Order By die ganze Geschichte auch noch sortieren.

[12:20] Das wäre es also.

[12:21] Select Spalten from Tabellen, where Bedingung, Group By Spalten,

[12:26] Having Bedingung, Order By Spalten.

[12:30] Das wäre also so ein Select-Statement.

[12:33] Und dazu kann man jetzt natürlich bestimmte Fragen stellen.

[12:35] Ja, wie baue ich das jetzt auf, wenn ich von mehreren Tabellen selektiere?

[12:38] Und wie kriege ich die zusammen?

[12:39] Und da kommen wir auch gleich noch zu, zum Thema Joins.

[12:41] Aber grundsätzlich erstmal der Aufbau.

[12:43] Da sollte man also mindestens die Sachen hier nennen.

[12:45] Die sind auch alle im Standard enthalten und die kann auch wirklich jede Datenbank abbilden.

[12:49] Ja, dann gehen wir nochmal von vorne nach hinten so ein bisschen durch,

[12:51] gucken uns mal so ein paar Feinheiten an, die auch gerne mal gefragt werden können in Prüfungen.

[12:55] Fangen wir ganz vorne an mit dem Select.

[12:57] Da gibt es ja noch ein Select Distinct.

[12:59] Was macht denn das Distinct?

[13:01] Da ist die Antwort relativ einfach.

[13:03] Ich liefere aus einer Ergebnismenge nur die eindeutigen Werte.

[13:07] Beispiel, ich habe in meiner Personendatenbank ganz viele Leute,

[13:10] die Macke mit Nachname heißen.

[13:12] Dann kann ich ein Select Distinct Nachname machen.

[13:15] Und dann bekomme ich nur einmal den Nachnamen Macke geliefert

[13:18] und nicht 73 Mal, weil 73 Datensätze in der Datenbank stehen.

[13:22] Und das Distinct kann ich natürlich auch auf mehrere Spalten anwenden.

[13:25] Also wenn ich einfach auch eine Kombination von Spalten eindeutig geliefert haben möchte,

[13:30] dann mache ich eben Select Distinct.

[13:32] Damit kann ich also in verschiedenen Anwendungsfällen genau das erreichen,

[13:37] dass ich mir eben nur anschauen will, welche unterschiedlichen Ausprägungen es gibt.

[13:41] Aber mich interessiert einfach nicht, wie oft die einzelne Ausprägung auftritt.

[13:45] Ich will nur wissen, wie viele verschiedene Werte gibt es denn.

[13:48] Dafür kann ich ein Select Distinct sehr gut benutzen.

[13:51] Ja, dann geht es weiter.

[13:53] Select, Spalten, From, Tabellen.

[13:55] Und jetzt geht es eigentlich schon los mit den Joins.

[13:57] Beim From könnte man ja schon die ersten mehreren Tabellen angeben.

[14:01] Und da ist jetzt die Frage, wie kann ich diese Tabellen jetzt verknüpfen?

[14:05] Welche Joins gibt es denn so in SQL?

[14:08] Das ist also eine Standardfrage, die wir ganz häufig stellen.

[14:11] Und da ist eigentlich die Antwort, es gibt den Inner-Join, es gibt den Outer-Join und es gibt den Natural-Join.

[14:16] Das sind so die groben drei, die man unterteilen könnte.

[14:19] Den Outer-Join könnte man noch weiter unterteilen in Left, Right und Full Outer-Join.

[14:24] Aber wir gehen einfach mal der Reihe nach durch.

[14:26] Der Standard-Join, wenn ich also nichts angebe, ist erstmal der Inner-Join.

[14:31] Was macht der Inner-Join?

[14:32] Der Inner-Join joint genau zwei Tabellen anhand von angegebenen Spalten.

[14:38] Ich kann also sagen, die eine Tabelle joint die bitte mit der anderen

[14:41] und nimm bitte diese Spalte aus Tabelle A und die andere Spalte aus Tabelle B.

[14:45] Und wenn die Werte der Datensätze in diesen Spalten übereinstimmen,

[14:48] dann wird der gesamte Datensatz aus Tabelle A verknüpft mit dem Datensatz aus Tabelle B ausgegeben.

[14:54] Und der wird nur genau dann ausgegeben, wenn auch wirklich auf beiden Seiten ein übereinstimmendes Merkmal da ist.

[15:01] Also wenn ich zum Beispiel einen aus der Personentabelle etwas selektiere

[15:05] und dann zu der Personen-ID aus einer anderen Tabelle die Adresse lese,

[15:09] dann wird nur dann ein Datensatz ausgegeben, wenn sowohl die Person als auch die zugehörige Adresse

[15:15] mit dem Fremdschlüssel auf die Person vielleicht vorhanden ist.

[15:18] Also wenn es eine Person gibt, aber die keine Adresse hat,

[15:21] dann wird der gesamte Datensatz nicht ausgegeben.

[15:24] Das ist ganz wichtig.

[15:25] Der Inner-Join gibt wirklich nur die Datensätze zurück, wo eine Verknüpfung möglich ist

[15:31] und alle notwendigen Schlüsselbeziehungen, alle Felder gefüllt sind.

[15:35] Demgegenüber steht dann der Outer-Join.

[15:38] Da ist es nicht zwangsläufig so, dass nur die Datensätze ausgegeben werden, die eine Übereinstimmung haben,

[15:44] sondern hier kann ich gezielt sagen, ich möchte auch die Datensätze angezeigt bekommen,

[15:47] wo es keine passende Übereinstimmung gibt.

[15:49] Und je nachdem, auf welcher Seite der Tabellenbeziehung ich das mache,

[15:53] nehme ich eben ein Left- oder ein Right-Outer-Join.

[15:56] Gucken wir uns das Ganze nochmal an.

[15:58] Person hat Adresse.

[16:00] Wenn ich also jetzt aus der Personentabelle mir die Person lese und mit einem Inner-Join mit der Adresse verknüpfe,

[16:06] dann werden die Personen, die keine Adresse haben, nicht in der Liste erscheinen.

[16:10] Wenn ich jetzt aber stattdessen einen Left-Outer-Join mache,

[16:14] dann werden die Datensätze aus der linken Tabelle angezeigt,

[16:18] auch wenn sie keine Entsprechung in der rechten Tabelle haben.

[16:21] In unserem Beispiel, wenn ich Person mit Adresse verknüpfe und ich mache einen Left-Outer-Join,

[16:27] dann wird aus der linken Tabelle, also der Personentabelle, werden alle Datensätze angezeigt.

[16:32] Und aus der rechten Tabelle, aus der Adresse, wo vielleicht bestimmte Personen gar keine Adresse haben,

[16:38] dann werden halt eben Null-Werte angezeigt.

[16:41] Das ist dann ganz wichtig zu wissen beim Outer-Join.

[16:43] Alle Datensätze, die keine Entsprechung haben, werden eben als Null dargestellt.

[16:47] Nochmal ganz kurz zusammengefasst.

[16:50] Left-Outer-Join, Person und Adresse werden also alle Personen angezeigt,

[16:54] egal ob sie eine Adresse haben oder nicht.

[16:57] Wenn sie eine Adresse haben, wird natürlich die Adresse ausgegeben.

[16:59] Wenn sie keine haben, werden für alle Adressspalten eben Null-Werte ausgegeben.

[17:05] Und das Ganze kann ich auch umdrehen.

[17:07] Wenn ich jetzt also einen Right-Outer-Join mache beim gleichen Beispiel,

[17:10] bedeutet das, es werden halt eben alle Adressen ausgegeben,

[17:14] auch wenn es Adressen gibt, die vielleicht gar keine Personen haben.

[17:17] Dann werden also eventuell Personen nicht ausgegeben, die keine Adresse haben,

[17:21] aber auf jeden Fall werden alle Adressen ausgegeben, auch wenn keine Person zugeordnet ist.

[17:26] Und jetzt kann ich das Ganze noch in beide Richtungen machen.

[17:28] Dann habe ich einen Full-Outer-Join.

[17:31] Das bedeutet dann, dass sowohl alle Personen als auch alle Adressen ausgegeben werden,

[17:36] egal ob auf der Gegenseite etwas existiert oder nicht.

[17:39] Das heißt, ich kann sowohl Personen und Adressen haben,

[17:42] die übereinstimmen und einen gesamten Datensatz darstellen,

[17:45] oder ich kann nur Personen haben und die Adressdaten auf Null gesetzt haben,

[17:48] oder umgekehrt, ich habe die Personendaten auf Null und die Adressdaten sind gefüllt.

[17:52] Das würde mir alles ein Full-Outer-Join liefern.

[17:56] Der letzte Join, den man davon abgrenzen müsste, wäre der Natural-Join.

[18:00] Der Natural-Join, da muss ich gar keine Spaltenverknüpfungsbeziehung angeben.

[18:05] Also wenn ich gerade sage, bei unserem Beispiel mit der Person und der Adresse,

[18:09] dann müsste ich vielleicht die PersonID als Fremdschlüssel in der Adressetabelle hinterlegen

[18:16] und dann eben sagen, where Adresse.PersonID gleich Person.PersonID.

[18:21] Und wenn ich das weglasse, dann gibt es noch die Möglichkeit, einen Natural-Join zu machen.

[18:25] Und da guckt jetzt die Datenbank selber, ob in den verknüpften Tabellen Spalten vorhanden sind,

[18:30] die denselben Namen haben.

[18:32] Und wenn das der Fall ist, dann verknüpft die Datenbank automatisch anhand dieser übereinstimmenden Spaltennamen die Datensätze.

[18:39] Beispiel, ich habe in meiner Person-Tabelle eben die PersonID

[18:44] und wenn ich jetzt in meiner Adressetabelle auch eine Spalte habe, die exakt PersonID auch heißt

[18:49] und ich mache dann einen Natural-Join, was ich allerdings explizit angeben muss,

[18:53] ich muss wirklich Natural da hinschreiben,

[18:55] dann guckt die Datenbank, oh, welche Spalten gibt es denn, die den gleichen Namen haben?

[18:58] Ah, siehe da, PersonID gibt es in beiden Tabellen.

[19:01] Also gucken wir doch einfach alle die Datensätze, wo diese Werte in der PersonID übereinstimmen,

[19:07] ganz normal wie beim inneren Join auch, die werden automatisch verknüpft und ausgegeben.

[19:12] Da kann ich mir also die Definition der zuzuordnenden Tabellenspalten sparen,

[19:17] hat aber natürlich, wie gesagt, die Voraussetzung, dass die Spalten gleich heißen müssen.

[19:22] Und das ist in sehr vielen Tabellen nicht der Fall.

[19:25] Sogar in meinem Beispiel würde ich es nicht so machen.

[19:27] Wenn ich eine Tabelle Person habe, dann nenne ich die PersonID doch nicht PersonID.

[19:32] Das wäre ja völlig redundant.

[19:33] Ich würde die einfach ID nennen.

[19:35] Das ist meine persönliche Meinung, Person.ID.

[19:38] Wenn ich jetzt aber in die Adresstabelle gehe und ich habe dort einen Fremdschlüssel auf die PersonID,

[19:42] dann muss ich sie natürlich PersonID nennen.

[19:45] Denn die Spalte ID wäre natürlich die ID der Adresse und nicht der Person.

[19:49] Das heißt, in meiner Tabelle Adresse hätte ich nachher eine Spalte ID, das wäre die AdressID,

[19:54] und eine Spalte PersonID, und das wäre der Fremdschlüssel auf die Tabelle Person.

[19:58] Und da sieht man schon,

[20:00] Es gibt zwar dann eine Spalte beim Natural Join, die übereinstimmt, nämlich ID und ID,

[20:04] aber es sind leider die völlig falschen IDs. Es ist einmal die PersonID und einmal die AdressID.

[20:08] Die passen gar nicht zusammen.

[20:09] Das heißt, ein Natural Join, sage ich mal, in der Wildnis anzutreffen,

[20:13] ich persönlich habe noch nie einen genutzt und ich habe auch noch nie einen gesehen,

[20:15] weil es einfach auch super fehleranfällig ist.

[20:17] Sobald ich einfach eine Spalte einfüge in die andere Tabelle und die zufällig in der anderen Tabelle,

[20:22] die verknüpft ist, existiert, dann wird die natürlich bei einem Natural Join angezogen

[20:26] und auf einmal ist vielleicht meine Ergebnismenge leer.

[20:28] Also, ganz vorsichtig wäre ich damit, ich bevorzuge immer die explizite Angabe von Verknüpfungen.

[20:35] Also explizit zu sagen, inner oder outer join, aber auch, welche Spalte mit welcher anderen in Verbindung steht.

[20:41] Denn Benennung, das wissen wir alle auch aus der Programmierung, das ist immer so ein heikles Thema.

[20:45] Und wenn dann entschieden wird, die Spalte wieder umzubenennen,

[20:49] dann muss ich meine Select Statements anpassen und so weiter.

[20:51] Das würde ich mir unbedingt sparen.

[20:52] Ich würde niemals ein Natural Join benutzen, sondern immer ein inner oder outer join

[20:57] unter Angabe der Beziehungen.

[20:59] So, das soll jetzt auch reichen zu den Joins.

[21:01] Dann machen wir mal weiter mit der nächsten Frage.

[21:03] Was ist eine Aggregatsfunktion?

[21:06] Eine Aggregatsfunktion, erst einmal wie der Name schon sagt, die aggregiert Werte.

[21:11] Und eine Aggregation bedeutet immer, ich habe mehrere Werte und ich mache die zu einem Wert.

[21:15] Und die klassischen Beispiele sind sowas wie Summe, Anzahl, Mittelwert.

[21:19] Wenn ich sowas mache wie Select Count Sternchen from Person,

[21:23] dann kriege ich halt die Anzahl der Personen in dieser Tabelle.

[21:26] Das heißt, normalerweise habe ich mehrere Datensätze, vielleicht sogar mehrere tausend Millionen Datensätze.

[21:30] Und mit dieser Count oder Sum Funktion kriege ich halt einen einzigen Wert,

[21:34] der diese gesamten Datensätze aggregiert.

[21:37] Anderes Beispiel wäre sowas wie Select Sum Gehalt from Person,

[21:41] um eben die Summe des Gehalts aller Mitarbeiter zu ermitteln.

[21:46] Das sind also Aggregatsfunktionen. Davon gibt es mehrere.

[21:49] Sum, Count, Average, solche Sachen.

[21:54] Je nachdem, was man mit der Datenbank so machen will, ist es immer sinnvoll, diese Aggregatsfunktionen auch zu benutzen.

[21:59] Man könnte ja auch auf die Idee kommen, sowas zu machen, Select Sternchen from Person.

[22:03] Und dann gehe ich in meiner Programmiersprache die ganzen Personen durch und summiere zum Beispiel das Gehalt.

[22:07] Ist aber die denkbar schlechteste Lösung, um solche Probleme zu lösen.

[22:11] Alles, was man in der Datenbank machen lassen kann, sollte man sie auch machen,

[22:14] weil die diese Sachen einfach viel besser kann.

[22:16] Heißt, schneller kann, als das in der Programmiersprache möglich ist.

[22:20] Überlegen wir uns das Beispiel. Ich möchte die Summe aller Gehälter haben.

[22:22] Mache dafür ein Select Sternchen und laufe dann diese Datensätze in meiner Programmiersprache durch.

[22:26] Das bedeutet aber ja, dass die Datensätze mindestens einmal von der Datenbank in die Programmiersprache übertragen werden müssen

[22:32] und zum Beispiel übers Netzwerk laufen.

[22:34] Das heißt, ich übertrage eine gesamte Tabelle in meine Programmiersprache,

[22:37] die dann diese ganzen Sätze auch noch im Speicher halten muss,

[22:40] nur um am Ende eine einzige Summe herauszubekommen.

[22:43] Und das kann die Datenbank alles tun, ohne dass ich so einen riesengroßen Speicherverbrauch habe.

[22:47] Das heißt, eine Aggregatsfunktion sollte ich immer, immer, immer benutzen,

[22:51] wenn ich solche Abfragen machen möchte,

[22:53] denn die Datenbank ist halt eben darauf optimiert, solche Massenverarbeitungen durchzuführen

[22:57] und in meiner Programmiersprache hat das nichts zu suchen.

[23:00] Also, Aggregatsfunktionen sind sehr, sehr wichtig, gerade auch, wenn es um die Performance geht.

[23:05] Und ja, so sollte man erklären können, wie das funktioniert.

[23:09] Haben wir es ja gerade gemacht.

[23:10] Dazu bietet sich dann die weitere Frage an, was macht ein Group By?

[23:14] In unserem Select Statement steht relativ weit hinten halt die Group By-Klausel.

[23:18] Was macht man damit?

[23:19] Ja, damit kann man im Zusammenhang mit einer Aggregatsfunktion bestimmte Spalten gruppieren,

[23:25] beziehungsweise seine Menge nach diesen Spalten gruppieren.

[23:28] Was bedeutet das?

[23:29] Wenn wir uns das Beispiel von eben nochmal nehmen, ich habe eine Personentabelle

[23:32] und mache jetzt halt Select Sum Gehalt aus dieser Personentabelle,

[23:36] dann kriege ich halt eben die Gesamtsumme aller Gehälter.

[23:39] Wenn ich jetzt diese Summe aber weiter unterteilen möchte, unterscheiden möchte,

[23:42] zum Beispiel nach meiner Abteilung.

[23:44] Angenommen, die Person hätte auch eine Abteilung in ihrem Datensatz stehen,

[23:47] dann könnte ich machen Select Sum Gehalt from Person und dann irgendwann später Group By Abteilung.

[23:54] Das bedeutet dann, ich würde nicht nur eine Summe bekommen,

[23:56] sondern ich würde aufgeteilt nach Abteilungen, die jeweils Untersumme bekommen, wenn man so will.

[24:02] Das steht dann also zum Beispiel, die Abteilung EDV verdient insgesamt so und so viel,

[24:06] die Abteilung XY verdient die Summe, was auch immer.

[24:10] Und wenn ich sowas haben will, brauche ich eben ein Group By.

[24:13] Was muss man beim Group By berücksichtigen?

[24:15] Das ist auch immer etwas, was ich in den schriftlichen Prüfungen ständig sehe,

[24:18] dass die Prüflinge das nicht auf Reihe kriegen.

[24:20] Wenn ich ein Group By mache, gebe ich ja dahinter an, nach welchen Spalten ich kopieren möchte.

[24:25] Also in meinem Beispiel von eben, Group By Abteilung.

[24:28] Das bedeutet aber, dass diese Spalten, die in dem Group By stehen,

[24:31] auch unbedingt oben im Select stehen müssen.

[24:34] Also ich kann die nicht oben weglassen.

[24:36] Ich kann nicht einfach machen Select Sum Gehalt und dann hinten Group By Abteilung.

[24:41] Das geht nicht, sondern ich muss immer auch die Abteilung mitselektieren.

[24:44] Denn wie sollte ich sonst nachher unterscheiden, welche Summe ich denn sehe?

[24:47] Wenn ich mache Select Sum und nachher ein Group By Abteilung und ich kriege einfach nur 5 Zahlen als Ergebnis,

[24:53] woher soll ich denn dann wissen, welche Abteilung jetzt welcher Summe zugrunde werden soll?

[24:57] Das geht gar nicht. Das kann man nicht unterscheiden.

[24:59] Deswegen müssen alle diese Spalten auch im Select stehen.

[25:02] Also unsere Abfrage hätte eigentlich so aussehen müssen.

[25:04] Select Abteilung Sum Gehalt und dann hinten Group By Abteilung.

[25:10] Das wäre in Ordnung.

[25:11] Und ganz wichtig ist, andersherum gilt das Gleiche.

[25:14] Wenn ich in meinem Select Statement mehrere Spalten habe, dann müssen die auch alle im Group By stehen.

[25:19] Ich kann also nicht so etwas machen wie Select Abteilung Name Vorname Sum Gehalt

[25:24] und dann am Ende nur Group By Abteilung.

[25:26] Das funktioniert nicht, sondern die müssen dann alle im Group By stehen.

[25:30] Und in diesem Beispiel wäre das dann ziemlich unsinnig.

[25:32] Dann hätte ich nämlich hinten Group By Abteilung Name Vorname und das hieße,

[25:35] ich habe das Gehalt für jede Person individuell.

[25:37] Und das ist natürlich nicht das, was ich haben will.

[25:39] Schlechtes Beispiel, aber wichtig zu merken.

[25:42] Alles, was im Select vor der Aggregatsfunktion steht, muss auch im Group By stehen und umgekehrt.

[25:48] Damit wir jetzt schon mit den interessanten Fragen zur Syntax durch,

[25:54] dann kommen wir noch zu einer letzten Frage, die ich noch im Bereich SQL anordnen würde.

[25:58] Und zwar, welche Datentypen gibt es denn in Datenbanken?

[26:02] Und da würde ich persönlich mich reduzieren auf drei, die eigentlich sinnvoll sind.

[26:07] Und alle anderen, die kann man theoretisch weglassen oder auch durch diese drei Basisdatentypen irgendwie abbilden.

[26:13] Ich würde jetzt erst mal mich darauf fokussieren zu sagen, es gibt Zeichenketten, Zahlen und Datum.

[26:19] Das ist so das, was interessant ist.

[26:21] Und darauf würde ich mich zum Beispiel auch in der schriftlichen Prüfung reduzieren.

[26:24] Also wenn ich irgendwie eine Aufgabe gestellt bekomme, definieren Sie mal eine Tabelle und definieren Sie auch die Datentypen.

[26:28] Dann würde ich mich auf diese drei grundsätzlichen Basisdatentypen, sage ich mal, reduzieren.

[26:33] Grundsätzlich ist es nämlich so, dass fast jede Datenbank irgendwie unterschiedliche Bezeichnungen für ihre Datentypen benutzt.

[26:38] Also in Oracle gibt es zum Beispiel den Datentypen Number.

[26:42] Damit kann man Ganzzahlen, aber auch Gleichkommazahlen darstellen.

[26:45] Ich kann also sagen Number 8, dann habe ich halt eine achtstellige Zahl.

[26:48] Ich kann aber auch sagen Number 8,2 und dann habe ich halt eine achtstellige Zahl mit noch zwei Nachkommastellen.

[26:55] Und das sieht in anderen Datenbanken vielleicht ganz anders aus.

[26:58] Da gibt es vielleicht Decimal als Datentyp oder Float oder was auch immer.

[27:02] Und das ist also nicht standardisiert und jede Datenbank macht da so ihr eigenes Ding.

[27:05] Und jede Datenbank hat auch noch unterschiedliche Datentypen, die sie zusätzlich anbietet.

[27:08] Zum Beispiel gibt es vielleicht Datenbanken, die einen Bool anbieten.

[27:11] Oder Text oder vielleicht sogar einen Blob, wo ich Binärdaten reinpacken kann.

[27:16] Oder weiß der Geier was, XML und JSON Datenbank.

[27:18] Da gibt es ja alles mögliche, was man heutzutage in eine Datenbank packen kann.

[27:21] Und da gibt es sogar dann individuelle Datentypen dafür, die auch bestimmte Optimierungen anbieten.

[27:26] Da kann ich zum Beispiel in der Oracle-Datenbank XML ablegen und wirklich mit XPath auf diesen XML-Dokumenten suchen in meiner SQL-Abfrage.

[27:34] Und das ist allerdings alles nicht standardisiert und gehört nicht zum SQL-Standard-Syntax dazu,

[27:39] sondern ist dann individuelle Erweiterung der jeweiligen Datenbank.

[27:42] Und bei den Datentypen ist mir persönlich nicht bekannt, dass es überhaupt irgendwelche standardisierten Datentypen gibt.

[27:48] Deswegen sage ich einfach, reduziert euch auf Zeichenketten, Zahlen und Datum.

[27:52] Und damit kann eigentlich jeder Sachverhalt in einer Datenbank abgebildet werden.

[27:57] Wenn ich zum Beispiel so etwas bräuchte, wie ein Bool, wahr oder falsch,

[28:00] dann könnte ich das zum Beispiel einfach mit einer einstelligen Zahl abbilden, entweder 0 oder 1.

[28:05] Das würde also reichen, damit könnte ich ein Bool abbilden.

[28:07] Ich würde mich darauf reduzieren, der Einfachheit halber.

[28:11] Wenn dann sowieso jede Datenbank ihre eigene Benennung hat, dann hat man vielleicht das Problem,

[28:15] dass die Prüfer die Benennung nicht kennen und dann sagen, den gibt es doch in meiner Datenbank, mit der ich arbeite, gar nicht.

[28:19] Also kann das auch nicht in der Prüfung richtig sein und so weiter.

[28:22] Also alles Problem. Ich würde einfach sagen, String, Zahl, Datum.

[28:26] Und bei Zahl natürlich Gleitkommastelle angegeben oder nicht.

[28:29] Das heißt auch Ganzzahl oder Gleitkommazahl. Das sollte ausreichen.

[28:33] Datum wäre insbesondere deswegen sinnvoll. Man könnte das natürlich auch als String abbilden.

[28:37] Sowas wie 2015-01-01 oder so.

[28:40] Aber das ist natürlich denkbar ungünstig, denn ganz viele Abfragen machen mit diesen Daten irgendwas.

[28:45] Also zum Beispiel Bestellungen zwischen dem 01.01. und dem 01.02.

[28:49] Und wenn ich dann mit String-Manipulationen rumeiern muss, das ist nicht gut.

[28:52] Also Datum wäre schon ein sehr wichtiger Datentyp, weil auch so ziemlich alle Datenbanken auch Datumsfunktionen anbieten.

[28:57] Und da wäre es dumm, wenn ich das also als Zahl oder als String abbilden würde.

[29:01] Deswegen würde ich diesen dritten noch dazunehmen.

[29:04] Und je nachdem, wie die Datenbank halt heißt.

[29:06] So eine Zeichenkette ist ganz häufig sowas wie Varchar oder in Oracle zum Beispiel Varchar2.

[29:12] Oder in anderen Datenbanken gibt es vielleicht sogar einen Text.

[29:15] Das heißt also wirklich einen Freitext. Da kann man quasi ein ganzes Buch reinschreiben, wenn man will.

[29:19] Oder es gibt eben Zahlen, die könnten Number oder Float oder sogar Int oder Integer heißen.

[29:24] Das ist also auch alles wild durcheinander, je nachdem, welche Datenbank man sich anguckt.

[29:27] Und Datum ist eigentlich relativ simpel. Das ist meist einfach Date.

[29:31] Eventuell noch mit DateTime zusammen oder nur Time.

[29:34] Aber diese drei Gruppen, darauf würde ich mich reduzieren.

[29:36] Damit kann ich normalerweise alles abbilden.

[29:39] Gut, das war es für heute. Wir kratzen wieder an den 30 Minuten.

[29:43] Ich habe geschafft, was ich schaffen wollte.

[29:45] Nämlich zumindest die häufigen Fragen zum Thema SQL zu stellen.

[29:48] Ich habe noch ein paar Datenbankfragen in der Hinterhand.

[29:50] Insbesondere im Bereich Modellierung, Transaktionen und so weiter.

[29:53] Da könnte man noch mal kurz darauf eingehen.

[29:55] Aber die schaffe ich jetzt heute nicht mehr.

[29:57] Werden dann in einer der nächsten Folgen behandelt.

[30:00] Ich hoffe, es hat euch ein bisschen geholfen, was ich euch heute erzählt habe.

[30:04] SQL, wie gesagt, ist ein ganz wichtiges Ding in der Abschlussprüfung.

[30:09] Sowohl in der schriftlichen als auch in der mündlichen wird das immer gerne gefragt.

[30:12] Von daher unbedingt noch mal anschauen.

[30:14] Wenn ihr dann nicht mehr ganz so sattelfest seid,

[30:16] da ist die Chance relativ hoch, dass das in so einer Abschlussprüfung gefragt wird.

[30:21] Damit wäre ich am Ende der heutigen Episode angekommen.

[30:25] Wie immer findet ihr die Shownotes zur heutigen Episode unter

[30:29] anwöchsendwicklerpodcast.de

[30:31] slash 19 für die 19. Episode.

[30:34] Ich würde mich freuen, wenn ihr mir ein Feedback gebt oder mich weiterempfehlt.

[30:38] Gerne könnt ihr mir auch ein Review oder ein Rating bei iTunes hinterlassen

[30:42] unter anwöchsendwicklerpodcast.de

[30:44] slash iTunes.

[30:46] Das wird mir sehr helfen, denn das trägt dazu bei,

[30:48] dass der Podcast noch ein bisschen bekannter wird

[30:50] und ich vielleicht noch mehr Azubis bei der Prüfungsvorbereitung helfen kann.

[30:54] Ihr dürft mir auch gerne Fragen stellen.

[30:56] Alles, was ihr noch zur Prüfung wissen müsst oder noch nicht wisst,

[30:59] schreibt mir gerne Mail oder über das Kontaktformular auf der Website

[31:03] oder bei Twitter oder Xing oder wo auch immer.

[31:06] Ihr könnt mich gerne kontaktieren.

[31:08] Ich antworte auf alle Kontaktanfragen gerne.

[31:11] Und wenn es ein interessantes Thema ist,

[31:13] mache ich auch gerne einen Blogbeitrag oder eine Podcast-Episode draus.

[31:16] Also einfach melden und ich versuche, alles zu beantworten, was ich kriege.

[31:20] Und als allerletztes noch einmal der Hinweis.

[31:22] Wenn ihr wollt, könnt ihr euch auch zu meinem Newsletter anmelden

[31:25] unter anwendungsentwicklerpodcast.de slash newsletter.

[31:29] Da bekommt ihr als kleines Dankeschön direkt eine E-Mail

[31:33] mit drei Checklisten für eure Prüfungsvorbereitung.

[31:37] Einmal für eure Projektdokumentation, für eure Projektpräsentation

[31:40] und auch für den Projektantrag.

[31:41] Da könnt ihr nochmal durchgehen, bevor ihr die Sachen einreicht,

[31:43] ob ihr an alles gedacht habt oder ob da vielleicht noch Sachen drin sind,

[31:46] die ihr noch optimieren könntet.

[31:49] Die wurden bislang rege downgeloadet

[31:51] und haben dem einen oder anderen sicherlich auch schon geholfen.

[31:55] Und wenn ihr auch noch Ideen habt, was auf der Liste ergänzt werden soll,

[31:58] dann bitte her damit.

[31:59] Die ist also jederzeit in Arbeit.

[32:01] Auf der Projektdokumentationscheckliste sind aktuell über 100 Punkte schon drauf,

[32:05] die ihr prüfen könnt, bevor ihr die Doku einreicht.

[32:08] Also da ist wahrscheinlich für jeden Prüfling was dabei.

[32:11] Wie gesagt, anwendungsentwicklerpodcast.de slash newsletter.

[32:14] Wenn euch die Inhalte nicht mehr gefallen, ihr könnt euch jederzeit abmelden.

[32:16] Geht also keinerlei Verpflichtungen oder sonstiges ein.

[32:19] Und ihr bekommt dann einmal in der Woche von mir den Newsletter

[32:21] mit den Infos zu den neuesten Artikeln und der Podcast-Episode.

[32:24] Und auch meine Links der Woche, die es immer Freitag gibt,

[32:27] bekommt ihr direkt dann schon am Montag per E-Mail.

[32:30] Also habt ihr noch so einen kleinen Vorteil, was die Geschwindigkeit angeht.

[32:34] Ja, dann würde ich sagen, machen wir Schluss für heute.

[32:37] Ich sage nochmal vielen, vielen Dank fürs Zuhören

[32:40] und bis zum nächsten Mal. Tschüss!

[32:51] Untertitel der Amara.org-Community