Transcript: PP05 - Datenbanken

Ja, hallo liebe Hörerinnen und Hörer. Willkommen beim Python-Podcast in der mittlerweile fünften Episode.

Heute geht es ein bisschen um Datenmanken.

Ja, wir haben wieder diesen schönen Wintergarten vor uns.

Ich bin der Dominik und natürlich dabei ist wie immer der Jochen.

Jo, hallo. Genau, Datenmanken. Ja, voll gut. Da freue ich mich schon drauf.

Das ist irgendwie ein Thema, mit dem ich schon viel zu tun hatte.

Das wird wahrscheinlich eine ein bisschen längere Episode.

Wir versuchen wieder ein bisschen Struktur reinzubekommen.

Wir wissen noch nicht ganz, ob das gelingt. Wir werden wieder hemmungslos abschweifen.

Wenn ihr Fragen, Anmerkungen dazu habt, Kommentare, Lob, alles, was ihr uns mitteilen wollt,

schickt eine E-Mail an hallo at python-podcast.de

Und wie immer findet ihr die Links und zusätzliche Infos der Sendung in den Shownotes.

Ja, wollen wir das eigentlich vielleicht noch erwähnen, welches Datum wir haben?

Heute ist der 24.02.2019.

Oh, wir machen jetzt mit Daten. Ja, finde ich gut.

Genau, wir haben das glaube ich schon mal gemacht.

Ja, haben wir das schon mal gemacht?

Ja, ich glaube in der ersten. Und dann haben wir es irgendwie nicht mehr gemacht.

Aber ich glaube, es ist wahrscheinlich eigentlich ganz interessant, wenn man das hört,

von wann das aufgenommen wurde.

Ja, stimmt. Ende Februar 19.

Und es ist gerade ganz gutes Wetter und es ist ein Sonntag.

Ja.

Normalerweise nehmen wir immer abends auf.

Heute ausnahmsweise mal nach dem Brunchen.

War irgendwie super lecker.

Ja, ich würde sagen, wir steigen fast direkt ins Thema ein.

Und es geht halt so ein bisschen darum, ja, das ist glaube ich nicht das erste Mal,

dass wir versuchen, so eine Folge mit Datenbanken zu strukturieren.

Das war auch der Grund, warum wir so ein bisschen länger auf die letzte Folge warten mussten.

Hatten wir ja kurz erwähnt.

Ja, was ist überhaupt so eine Datenbank, Jochen?

Und wir versuchen halt immer wieder, euch vielleicht kurz zu erklären,

was man damit noch mit Python machen kann oder welche Module es dafür gibt.

Aber das vielleicht mal als Warnung.

Python kommt in dieser Folge nicht nur vor und nicht ganz so viel,

sondern es geht halt tatsächlich darum, wie man das, was man mit Python macht,

also die Datenbanknutzung, so ein bisschen euch erklären, näher bringen kann.

Ja, wobei ich denke, dass das halt eigentlich für alle, die Python entwickeln wollen,

ein interessantes Thema ist, weil da wird man, egal in welchem Bereich man sich da tummelt,

nicht drumherum kommen, irgendwann etwas mit Datenbanken zu machen.

Und ja, dafür muss man sich halt dann auch nicht nur mit Python auskennen,

sondern muss halt auch so ein bisschen verstehen, wie das mit den Datenbanken funktioniert.

Und man kann halt nicht viel interessante Dinge machen,

wenn man halt von Datenbanken da gar nichts versteht.

Und insofern, ja.

Ja, wir werden noch ein bisschen darauf eingehen, was ist das überhaupt, ne?

Datenbanken, Unterschiede in einzelnen Datenbanktypen, ein bisschen darstellen.

Und wir wollen anhand eines kleinen Beispiels euch so ein bisschen so die Problematiken beim Skalieren

und bei dem Arbeiten mit der Datenbank erklären.

Genau.

Und da haben wir uns gedacht, nehmen wir einfach irgendwie etwas, was man halt kennt.

Ich meine, wozu ist das Internet da?

Irgendwie Dinge einkaufen, klar, weiß man ja.

So ein Buchladen, habe ich gehört, können wir als Beispiel nehmen.

Und genau, Amazon hat bestimmt die da schon mal benutzt und weiß halt, wie das funktioniert.

Und das ist halt eigentlich, denke ich, ein ganz gutes Beispiel für, wofür braucht man eigentlich Datenbanken?

Weil die haben wahrscheinlich auch für fast alle Datenbanktypen irgendwie eine Anwendung.

Und daran kann man das vielleicht ganz gut erklären.

Ja, dann vielleicht fangen wir erstmal einfach an.

Also mit was würde man einfacherweise anfangen?

Wenn man jetzt Python hat, möchte Daten haben, man könnte ja einfach so ein Dictionary jetzt nehmen oder sich eine

Liste erstellen und da irgendwie über Indizes iterieren.

Dann hätte man ja sowas wie einen kleinen Datensatz schon mal.

Ja, wenn man das Ganze jetzt mit etwas komplizierteren Daten braucht.

Wir hatten eben, glaube ich, im Vorgespräch ganz kurz über Struktur gesprochen.

Da gibt es eine Struktur, die man sich ausdenken muss.

Das ist gar nicht so trivial.

Das ist recht wichtig, dass man da so ein bisschen mehr Gedanken dazu macht.

Wie sieht denn meine Struktur der Daten überhaupt aus?

Und was soll ich denn damit machen?

Wie würdest du da direkt vorgehen?

Ja, also das ist halt, das kommt tatsächlich.

Auf den Anwendungsfall an und was ich halt in der Praxis im letzten Jahrzehnten so durchgesetzt

hat, sind relationale Datenbanken.

Aber es gibt halt auch diverse andere Arten von Datenbanken und die haben alle so ihre

Berechtigung.

Alle, die das noch nicht drauf haben, also so SQL oder NoSQL.

Ja, genannt oft.

Ja, genau.

Und ja, es hängt halt davon ab.

Also man kann natürlich auch einfach Objekte, Python-Objekte nehmen, die irgendwie serialisieren.

Nennt man das?

Also zum Beispiel gibt es da in der Steine.

In der Bibliothek das Pickle-Modul für, was halt aus einem Python-Objekt, das irgendwie

beliebig aussehen kann, macht das halt eine String- oder Byte-Repräsentation.

Also eine Serialisierung ist tatsächlich irgendwie die Darstellung als Zeichenkette

oder Byte-Strecke, damit man die übertragen kann über einen Kanal oder sowas.

Ja, genau.

Das nennt man Serialisierung.

Ist auch im Kontext von Datenbanken eine sehr wichtige Geschichte.

Und man könnte jetzt zum Beispiel diese Byte-Folgen oder Strings nehmen und die String-Folgen

halt zahlenweise in einen Pfeil reinschreiben und dann hinterher auch wieder auslesen.

Also man nimmt einfach zum Beispiel, wenn man jetzt den State von irgendeinem Programm

speichern möchte, nimmt man einfach alle Objekte, die man jetzt so findet oder die man sich

irgendwo gemerkt hat, dass man sie hat und serialisiert die halt in Pfeilen, schreibt

das Ganze in einen Pfeil.

Genau so habe ich das auch bei meiner ersten versuchten Datenbank-Operation selber gemacht,

nämlich einfach so die Daten, die ich hatte.

Es ging da um so Spielerdaten aus dem Sport, habe ich einfach alle Informationen über

einen Spieler in einem Spiel.

Und dann habe ich das Ganze in einem Spiel.

Und dann habe ich das Ganze in einem Spiel.

Und dann habe ich das Ganze in einem Spiel.

Und dann habe ich das Ganze in einem Spiel.

Und dann habe ich das Ganze in eine Zeile gepackt und die zahlenweise in eine Datei

reingeschrieben.

Genau.

Und dann, wenn man jetzt den Status wiederherstellen will des Programms, wenn man das startet,

dann nimmt das einfach die Datei, liest alles wieder ein und dann ist das im gleichen Zustand

wie vorher.

Und genau, wenn man das mit Python-Objekten macht, dann ist es halt nicht mehr menschenlesbar.

Aber man kann das halt genauso machen, indem man halt CSV schreibt oder sowas halt.

Dann wäre es halt noch menschenlesbar.

Da muss man sich halt überlegen, wie man die CSV.

in Objekte verwandelt oder Objekte wieder in CSV-Zeilen.

Ich habe einfach den Dictionary-Code in eine Teile reingeschrieben, habe das dann ausgelesen und evaluiert.

Das war wahrscheinlich nicht die beste Methode, das zu tun, aber funktioniert hat es trotzdem.

Genau.

Und wenn man sowas macht, das wurde am Anfang irgendwie bei Web-Entwicklung auch häufig gemacht.

Das nannte sich dann Flat-Files, Datenbank mit Flat-Files.

Man hat einfach den State da irgendwie rein.

Und natürlich ist auch das File-System ja schon irgendwie eine Art Datenbank.

Das ist halt eine hierarchische Datenbank, die halt so eine Baumstruktur hat.

Und deren Blätter halt Files sind, Wurzel ist halt Root/ bei Unix-Systemen oder bei Windows ist es irgendwie was komisches mit dem Laufwerksbuchstaben.

Und ja, das ist natürlich auch eine Struktur.

Man hat halt irgendwie darüber die Verzeichnis-Lese, die es da gibt, auch schon so Metadaten definiert, dass man halt weiß, so bestimmte Sachen sind halt in bestimmten Verzeichnissen so.

Und das Ganze gibt es halt auch über Netzwerk-Geschichten, indem man das so hierarchisch, die bekannteste hierarchische Datenbank im Netz.

Das ist halt so was wie LDAP, Windows nennt das irgendwie Active Directory oder ist auch vielleicht noch ein bisschen komplizierter.

Und ja, das ist halt schon mal eine grundsätzliche Art, wie man wie man Datenbanken betreiben kann.

Aber vielleicht etwas, was ich mich ganz gerne auch noch mal einsetzen würde, ist, wie Leute, also wenn man jetzt sich überlegt, wo könnten Leute etwas, das man sonst vielleicht mit Datenbanken tun könnte, irgendwie schon mal gesehen haben?

Oder was machen viele Leute?

Und wenn das halt eigentlich auch gut in den Datenbank-Kontext passt, dann würde ich vielleicht sogar eher mit sowas wie Excel oder so anfangen, weil das wird dann oft so scherzhaft auch erwähnt, wenn man sich überlegt, was ist die meisten verwendete, meisten ausgerollte Datenbank-Lösung der Welt, dann könnte man auch sagen, das ist halt Excel, weil viele Leute halt Excel quasi als Datenbank benutzen.

Allen möglichen Quatschen, irgendwelche Spalten und Teilen reinschreiben und ganz, ganz, ganz, ja.

Das ist, genau, das ist halt eigentlich, ach so, und vielleicht sollte man sich erstmal grundsätzlich überlegen, stimmt, wenn man schon so anfängt zu erklären, was Datenbanken sind, was ist denn eigentlich Daten, was sind eigentlich Informationen, was sind eigentlich Wissen, da hört man umgangssprachliche Definitionen, die halt, wo man dann weiß, was das ungefähr sein soll, aber wenn man das jetzt aus dem Datenbank-Kontext her präzisieren möchte, dann geht das eigentlich auch relativ schmerzlos, also Daten sind halt sowas wie, also ein Datum wäre,

irgendwas mit minus 3,5, wäre jetzt ein Datum, einfach nur ein Zahlenwert oder so, und das sagt einem halt natürlich noch nichts.

Weil es ja kein Bezug dafür ist, minus 3,5, was denn?

Ja, genau, richtig.

Grad Fahrenheit, ne?

Und, ja, wenn man jetzt von Informationen spricht, dann spricht man von Daten, die halt schon so ein bisschen Kontext haben, also sowas wie minus 3,5 Grad Temperatur, das heißt, man weiß halt, das steht jetzt in der Temperaturspeise,

und damit weiß man schon mal so ein bisschen, worum es da überhaupt geht, und dann nimmt man das Informationen, und das, was man aber eigentlich in Datenbanken speichern möchte, und dann was machen möchte, das ist irgendwie so Wissen, Begriff dafür ist Wissen,

und das wäre dann halt, wenn man jetzt eine ganze Reihe von Temperatursensoren hätte, die halt nicht nur die Temperatur über die Zeit irgendwie aufgenommen haben, sondern halt auch noch deren Positionen hat,

in einer Struktur, die halt bestimmte Anfragen leichter macht, halt gespeichert hätte, dann kann man damit möglicherweise das Wetter vorhersagen, oder sowas.

Das heißt, man hat halt Wissen über, wie das Wetter gerade ist, oder wie es war.

Oder man weiß zum Beispiel, dass es im Winter kälter wird als im Sommer.

Ja, genau, und dann kann man halt, wenn man Abfragen daran stellt, dann halt Schlussfolgerungen daraus ziehen, und dann vielleicht Dinge vorhersagen, oder halt auch einfach bestimmte Fragen beantwortet bekommen, die einen interessieren.

Also alle Städte, in denen es letztes Jahr kälter war, so und so, oder irgendwie sowas.

Ja, genau, das ist das, wofür man eigentlich Datenbanken verwenden möchte.

Oh, da kann man auch Analysen irgendwann machen. Das ist aber dann, glaube ich, wieder ein neues Thema, wie man Analysen dann mit Daten fährt.

Die werden wir heute, glaube ich, nicht machen.

Doch, doch, doch.

Ja, doch, doch, doch, alle.

Okay, ihr müsst heute lange, lange Geduld mitbringen, oder eine große Runde durch den Park, oder ihr könnt gerne zur Wohnung putzen, heute.

Ja, ich bin mal gespannt, wie schnell wir da durchkommen.

Aber ja, ich denke, das ist eigentlich vielleicht ganz interessant, mal so einen groben Überblick, also ich versuche dann zu verhindern,

zu sehr ins Detail zu gehen, aber wenn man einfach mal so das Gesamtthema Datenbanken mal überblickt hat.

Ja, ich halte ich so ungern davon ab, so ins Detail zu gehen, weil ich finde das unheimlich interessant, was da alles noch so drinter steckt.

Ich bin ja sehr curious, was man noch alles so findet und die Details sind halt auch irgendwie wichtig, ja.

Ja, stimmt. Wir schauen einfach mal. Ich hoffe mal, dass es nicht allzu lang wird, aber.

Okay, ja, dann fangen wir doch direkt mal mit dem Beispiel an, oder wolltest du noch so ein paar grundsätzliche Dinge über Daten?

Einmal grundsätzlich darüber, was gibt es für unterschiedliche Arten von Datenbanken, auch um halt dann, ja,

ja, um darauf dann wieder Bezug nehmen zu können in dem Beispiel und vielleicht auch das, was halt sich jetzt durchgesetzt hat.

Jedenfalls, das ist halt eben hierarchische Datenbanken, gab es schon ganz lange und ja, Sachen in Flatfiles oder irgendwie strukturierten Dateien hat man auch schon lange.

Und dann irgendwann 1971, glaube ich, ist ein Paper rausgekommen von Ted Kott und der hat sich halt Gedanken darüber gemacht, wie man eigentlich dieses Problem, ich möchte wissen, irgendwie speichern und dann irgendwie

Dinge damit später machen, wie man das so grundsätzlich angehen sollte und dessen Idee war halt, also ein Problem, was er gesehen hat mit den bisherigen Ansätzen war, dass viele Leute Zeit damit verbracht haben, die Daten, die sie halt schon auch irgendwie strukturiert, aber halt im eigenen Format in Dateien gespeichert haben, da Algorithmen für zu schreiben, wie die jetzt abzufragen sind.

Also, wenn man jetzt eben so eine Frage beantwortet haben möchte, wie, keine Ahnung.

Wie viel, was war denn jetzt die Stadt, in der es letztes Jahr am kältesten war in Deutschland oder so, dann fingen Leute an, dann Algorithmen zu schreiben, die für die Art, wie sie die Daten gespeichert hatten, halt, ja, das Problem gelöst haben, genau.

Und jeder, der halt die Daten irgendwie anders speichert, muss sich halt einen neuen Algorithmus überlegen, wie er das macht.

Und das ist ja eigentlich ziemlich blöde, also das wäre irgendwie schlauer, wenn man das standardisieren könnte und also nicht...

...sich überlegt, welchen Algorithmus oder einen Algorithmus zu schreiben, der halt das irgendwie abfragt, sondern zu beschreiben, was man haben möchte und dann irgendeine Art von Datenbank-Management-System, das dann halt weiß, wie man irgendwie diverse Arten von Indizes baut oder so, dem diese formalisierte Anfrage vorzulegen und das Ding sucht sich dann die beste Art, wie man das dann löst raus und macht das dann für einen.

Und damit das alles gut geht, muss man halt die Daten auch in einem bestimmten Format...

...speichern und man sollte die halt in Form von Relationen speichern.

Das heißt im Grunde mehr oder weniger wie in Tabellen, man kennt das halt aus Excel, wobei viele Excel-Tabellen halt nicht die Anforderungen erfüllen, die man eigentlich sozusagen dann dran stellen würde.

Weil in unterschiedlichen Spalten oder Zahlen irgendwie unterschiedliche Dinge drinstehen, die dann nicht zu suchen haben, oder?

Ja, weil sie halt nicht normalisiert sind, weil es nicht so wirkliche...

Oh, jetzt kommen wir direkt mit den Normalisierungen, ja.

Weil es nicht wirkliche Beziehungen zwischen Tabellen gibt und das in Datenbanken gibt es halt alles schon.

Und da gibt es dann auch bestimmte Regeln und Constraints irgendwie überprüft und so.

Tabellen, die auf Tabellen zeigen oder sowas.

Genau, genau.

Ja, und das wird in Excel halt alles nicht gemacht.

Und ja, das ist halt, das ist in der Praxis ein relativ großes Problem, denke ich.

Das ist halt, ich habe das, auf den kommen wir später noch zurück vielleicht.

Der heißt Simon Willison, der hat für den Guardian...

Vor zehn Jahren ungefähr irgendwie so im Bereich Datenjournalismus irgendwie, da gab es das schon.

Heute ist das ein großes Thema, aber damals hat das irgendwie keinen so richtig interessiert gearbeitet.

Und der ist halt eher so, hat was mit Datenbanken da zu tun.

Und da gab es schon jemanden, der sich damit beschäftigt hat, also von der Zeitung her.

Wenn es ein Artikel über irgendein Thema Arbeitslosigkeit oder keine Ahnung, irgendwas wirtschaftliche Themen irgendwie ging.

Wenn man da Schaubilder und Diagramme reinmachen wollte.

Wo kommen denn die Daten dafür eigentlich her?

Und er kannte irgendwie in allen Institutionen Leute, die er nach diesen Daten fragen konnte.

Wusste, wo man die bekommt und so, super.

Aber das Problem ist jetzt, also der Simon Willison, also er aus der Programmiererecke,

wollte halt die Daten auch anders noch zugänglich machen.

Und wollte halt gucken, ob man da nicht übergreifend irgendwelche Anfragen stellen kann.

Und fragte den dann so, wo denn die Daten wären oder wie er die denn speichern würde.

Und der sagte so, oh ja, ich habe da hier irgendwie ein paar tausend.

Excel-Files auf meinem Desktop.

Und da sind die halt drin.

Und ich weiß halt, in welchen Daten, in welchen Files.

Da ist so ein Ordner im Schrank, da kann ich mal blättern.

Und ich glaube, das ist tatsächlich eine Situation, die in vielen Unternehmen so ist oder so.

Dass man halt dann Experten hat dafür, für diese Domänen.

Die Menschen aus dem Archiv.

Ja, die aber dann nicht unbedingt jetzt so Datenmarktspezialisten sind.

Und die machen dann halt Excel-Files und tun das irgendwo hin.

Aber das funktioniert halt nicht gut, weil...

Man kann darüber jetzt keine übergreifenden Anfragen stellen.

Dann hat man auch so ein Problem, wenn man mit Leuten zusammenarbeitet.

Ja, wie ist das eigentlich, wenn mehrere Leute das jetzt ändern?

Dann gibt es auch wieder so komische Strategien, wie man hat das dann irgendwie auf einem Netzwerk-Share.

Und dann muss man sich irgendwie Bescheid sagen, wenn man das ändert.

Oder man macht das irgendwie über komisch benannte Dateinamen oder sowas.

Und das ist natürlich alles total furchtbar.

Also man benutzt dann im Grunde zwei Datenbanken, die nicht wirklich dafür geeignet sind,

was man dann macht.

Nämlich einmal das Filesystem, um halt so eine Art Versionskontrolle zu machen.

Und dann Excel als Datenbank, was halt auch nicht dafür geeignet ist.

Und dann macht man sich das Leben sehr, sehr schwer.

Obwohl es deutlich einfacher sein könnte.

Und ja, das sind aus meiner Perspektive auch so die beiden Dinge, wo man...

Wenn man Daten organisieren möchte.

Wenn man in Firmen so leichte Gewinne, die man machen könnte.

Also die beiden Themen, die halt vollkommen unter...

Unterschätzt sind, aus meiner Perspektive, sind einmal Versionskontrolle.

Also das sehe ich ganz oft, dass halt jetzt...

Also bei Programmierern, die wissen inzwischen, wie das funktioniert und machen das halt auch.

Und bei denen ist halt Verständnis, was jetzt Git ist und wie man das verwendet,

irgendwie durchaus angekommen.

Immer bitte den Git-Flow.

Ja.

Aber in den meisten anderen Abteilungen, wo es nicht um Programmieren geht,

die haben von solchen Dingen noch nie irgendwas gehört.

Da nimmt man Tipp-X und mal da kurz die Buchstaben, die falsch sind, raus und malt dann da drüber.

Und wenn man wüsste, was da vorher stand, dann muss man das Tipp-X abkasten.

Ja, die wissen halt vielleicht, wie sie ihre Programme bedienen oder so.

Aber die wissen gar nicht, dass sowas geht.

Und wissen gar nicht, wie das geht.

Und machen dann sehr umständlich das, was ihnen arbeitet.

Sehr fehleranfällig, die ihnen Git oder...

Tabelle 1, Tabelle 1 neu, Tabelle 1 neu, neu, neu, final.

Und ja, jetzt jetzt wirklich.

Also da könnte man mit wenig Aufwand...

Reichen.

Und eben auch da irgendwie, wenn man Daten speichert und halt auch...

Man hat ja in Excel dann oft nicht nur Daten, sondern man hat dann Daten und Logik,

weil man jetzt irgendwelche Reports erzeugt für irgendwie ein Management-Layer oder so.

Und dann ist das viel Handarbeit, wo im Grunde man, wenn man jetzt ein bisschen...

Ich habe das gerade gehört, das war gerade ein super kurzer kleiner Nebensatz.

Wenn man kurz irgendwelche Daten erzeugt, so für den Management-Layer.

Ja, das ist, denke ich, in Grundform viel.

Wenn die Leute da so Excel mit irgendwelchen Makros drin oder irgendwelche Skript-Schnipseln drin haben, warum die das verwenden.

Ja, das Problem ist halt, das funktioniert meistens und dann funktioniert es irgendwann nicht mehr oder die Daten ändern sich.

Und dann muss man halt irgendwie einen Teil von einem VBA-Skript oder so irgendwie so ein bisschen anpassen.

Und dann geht was an der anderen Stelle kaputt.

Und dann ist es auch so, dass man oft Sachen von Hand gefixt hat.

Also irgendwelche Werte sind halt nicht so, wie sie sein sollen.

Und bei Excel klickt man dann da rein und dann ändert man den Wert halt.

Und dann weiß man aber nicht, dass man das gemacht hat.

Und dann kommen jetzt neue Daten rein.

Die sind wieder falsch.

Und dann muss man es wieder ändern.

Oder es geht halt kaputt oder so.

Und das ist einfach so aus einer Programmierersicht nicht so das, was man tun sollte.

Das geht man dann mit Stunden, um Stunden, um Stunden, um Stunden.

Genau, aus Programmierersicht ist es so, wenn ich da irgendwie was ändere, dann ist das halt irgendwie Programmlogik.

Und wenn dann neue Daten reinkommen, dann wird die halt genauso angewendet.

Und dann muss ich das halt nur einmal hinschreiben.

Und dann ist es sozusagen für immer irgendwie gelöst.

Und ja, es gibt auch ganz in VBAs natürlich noch so ein...

Extra-Problem.

Das soll übrigens bei Python gehen, habe ich gehört.

Ja, ich weiß, dass bei Microsoft gibt es irgendwie so ein...

Die haben da auch so ein Priorisierungstool sozusagen.

Ich weiß nicht genau, was das ist.

Und ich glaube, das meiste nach Requested Feature ist es, VBA durch Python zu ersetzen.

Mit irgendwie tausenden Upvotes.

Aber ich glaube, definitiv dazu geäußert, ob das irgendwie dann kommt, hat sich da auch noch niemand.

Aber das wäre natürlich auch eine interessante Geschichte.

Aber man hat auch bei Python dann immer noch das Problem, was man halt wahrscheinlich...

eigentlich nicht machen können wird, ist sowas wie mit PIP irgendwie Dinge nachinstallieren oder so.

Selbst wenn es mit Python jetzt die VBA ersetzen würde.

Gut, man hätte schon den Vorteil natürlich, dass die Standard-Bibliothek von Python sehr viel mächtiger ist,

als das, was VBA kann.

Aber es ist halt immer noch nicht...

Also es gibt diverse Probleme, die noch gelöst werden müssten, damit das alles wirklich smooth ist.

Und das Grundproblem ist natürlich, dass Excel das vollkommen ungeeignete Tool ist für vieles,

was da in dem Bereich gemacht wird.

Ja, aber genau.

Also eigentlich wäre das, was viele Leute damit machen,

die wären viel besser bedient, wenn sie halt Python nehmen würden und eine relationale Datenbank.

Und weil die eben diese ganzen Geschichten auch löst.

Da gibt es dann halt, wenn da mehrere Leute drauf zugreifen und Dinge ändern,

dann sorgt die Datenbank dafür, oder das Datenbank-Management-System,

dass da nichts schief geht, dass alle Leute immer die gleichen Daten sehen,

jedenfalls innerhalb von einer Transaktion und so.

Und da gibt es auch die ganze Zugriffskontrolle und all das ist alles schon fertig implementiert.

Und ja, das ist halt so das, was Leute im Grunde verstehen, wenn man von Datenbanken spricht, denke ich.

Aber es gibt halt auch noch eine ganze Menge anderer Datenbanken.

Und dass sich relationale Datenbanken so durchgesetzt haben, ist auch aus meiner Perspektive ein Stück weit Glück.

Oder hängt halt an der Geschichte von einzelnen Firmen.

Also man hätte sich auch durchaus vorstellen können, dass sich andere Paradigmen durchgesetzt haben.

Hätten, haben sie aber irgendwie nicht.

Und jetzt sind halt so relationale Datenbanken das, was alle irgendwie verwenden.

Aber es ist auch gar nicht so ein schlechter Ansatz.

Insofern kann man damit eigentlich ganz gut leben.

Aber nur mal so um...

Der Vollständigkeit halber, ja.

Ja, der Vollständigkeit halber, um mal zu sagen, was es sonst noch alles gibt.

Es gibt halt Dokumentendatenbanken.

Ja, gibt es auch schon ganz lange.

LotusNotes ist ja so ein Beispiel für...

Populär.

CouchDB, MongoDB, die fallen auch in diesen Dokumentendatenbank-Bereich rein.

Lösen halt so ein bisschen unterschiedliche Probleme.

CouchDB löst so ein bisschen das Problem, dass ich nicht unbedingt in einen zentralen Master immer reinschreiben will.

Weil der halt auch weg sein kann, wenn ich zum Beispiel offline bin oder so.

Dann kann ich halt nicht da reinschreiben.

Sondern muss dann halt eventuell erst lokal schreiben.

Und dann irgendwie die Daten synchronisieren hinterher.

Und das macht CouchDB sehr schlau.

Verwendet tatsächlich auch einen Algorithmus, der aus dem LotusNotes-Dings-Projekt kommt.

Es gibt Key-Value-Stores, wo man einfach nur irgendeinen Hash irgendwie...

Also man kann sich das vorstellen wie ein Python-Dict.

Wo man halt irgendwelche Keys hat.

Und dann hat man irgendwelche Werte, die man dann zurückbekommt, wenn man den Key da hinschickt.

Darunter fallen so Sachen wie Redis oder Memcached.

Oder so oft zum Cache.

Aber manchmal können sie auch kompliziertere Sachen oder weiter strukturierte Daten.

Berkeley-DB war lange ganz groß.

Heute gar nicht mehr so sehr verwendet.

Ja, aber auch sowas wie Amazon Dynamo oder so fällt da auch drunter.

Und dann gibt es halt noch so spaltenorientierte Datenbanken.

Wobei ich auch da sagen würde, es gibt zwei unterschiedliche Arten.

Aber halt sowas wie Bigtable, wo Google einen Index drin speichert.

Oder das entsprechende Hadoop-Äquivalent.

Oder das Äquivalent aus dem Hadoop-Ökosystem Edgebase.

Die Dinger sind halt dafür gedacht, dass man da so ein bisschen mehr Daten hat.

Die Dinger sind halt dafür gedacht, gigantische Datenmengen irgendwie zu speichern.

Und das halt machen sie dann irgendwie eher so spaltbasiert.

Cassandra, Apache Cassandra ist auch so ein Projekt, das das genauso macht.

Dann ein komplett anderes Paradigma sind Grafendatenbanken.

Wo man Daten eben nicht in Tabellen speichert, sondern man speichert eher Knoten und Kanten.

Und die Relationen zwischen den Daten sind halt nicht dadurch dargestellt,

dass man jetzt halt irgendwie Zeilen in einer Tabelle hat.

Und dadurch, dass man halt beliebige Beziehungen im Grunde zwischen Knoten irgendwie hat,

das ist jetzt ein bisschen abstrakt.

Weiß ich auch gar nicht genau, wie ich das erklären kann.

Vielleicht kann man das nachher nochmal im praktischen Beispiel ein bisschen besser erläutern.

Vielleicht kann ich das nachher nochmal im praktischen Beispiel ein bisschen besser erläutern.

Genau.

Aber das ist halt so eine ganz andere Art von Datenbanken.

Da würde ich sagen, das hätte auch sich anstelle von relationalen Datenbanken durchsetzen können.

Ja.

Und genau, auch das, was mit dem Semantik-Web vielleicht haben manche Leute,

davon schon gehört, so RDF, Tuppel-Stores, das ist auch alles im Grunde Grafendatenbanken.

Okay, Semantik-Web, ja, machen wir später.

Genau.

Und dann gibt es natürlich noch so wirklich anwendungsspezifische Datenbanken,

sowas wie Volltext-Suchmaschinen, also Volltext-Indizes oder für Zeitreihen gibt es auch spezialisierte Geschichten,

Influx-DB oder Timescale-DB oder halt sowieso für, du hast halt ein bestimmtes Problem,

wie du möchtest dieses, bei Google sieht man halt, Google-Suggest hieß das Feature,

wenn man Google-Query eingibt, dann werden einem so Vorschläge gemacht.

Dafür braucht man halt spezielle Art, das zu indizieren, das ist Suffix-Trees.

Und das kann ja, ja, dafür gibt es dann auch wieder spezielle Server, mit denen man das machen kann und so.

Und das wäre jetzt etwas, was man sonst halt nicht so braucht.

Es gibt halt für bestimmte Anwendungsfälle gibt es sowas halt, aber ja, ist jetzt manchmal jetzt in solcher Funktion

in so verbreiteteren Datenbanken enthalten, aber es gibt halt auch mal spezialisierte Geschichten dafür.

Ja.

Vielleicht die ganzen Basissachen werden noch komplett nicht kurz erwähnt.

Ah ja, okay.

So, keine Ahnung, MySQL oder Postgres.

Ach so, das sind, ja genau, das sind Beispiele für relationale Datenbanken.

Ja, MySQL, Postgres, das wären jetzt die Open-Source-Vertreter.

Oracle und MSSQL-Server, Sybase, das wären so die kommerziellen.

Ja, Geschichten, DB2 von IBM, ja.

Oder zur Historie, im Grunde die, nachdem dieses Paper irgendwie, das ist übrigens sehr,

das sollte man nicht schon uns packen, das ist sehr empfehlenswert, das sich mal anzulesen von Headcourt.

Der hat damals bei IBM gearbeitet und da ist ein System daraus entstanden, das nennt sich System R.

Das haben irgendwie so ein paar Leute bei IBM geschrieben und daraus ist halt DB2,

auch von IBM entstanden irgendwann, aber halt Oracle bezieht sich auch da drauf, glaube ich.

Ich weiß jetzt aber nicht, wie die Verbindung zu Oracle ist.

Und dann gab es halt auch Leute in Berkeley, die versucht haben, das zu implementieren, das Paper.

Und dabei ist was rausgekommen namens Ingress.

Michael Stonebreaker war das damals und das war am Anfang noch gar keine Datenbank für beliebige Daten,

sondern das war für Bilder irgendwie.

Und dann ist das Ganze zu Postgres geworden.

Und wurde dann zu einer normalen, relationalen Datenbank sozusagen.

Und das ist auch faszinierend, also dieses ganze Postgres-Projekt ist der Wahnsinn eigentlich.

Das hat halt irgendwie Mitte der 80er ist das gestartet oder halt, wenn man Ingress dazu zählt, noch früher.

Und ist jetzt über 30 Jahre wahrscheinlich, hat das auch einen Buckel und ist immer noch top.

State of the Art.

State of the Art immer noch dabei.

Das kommt immer noch.

Tolle Sachen dazu.

Ist wahrscheinlich auch so die, sie nennen sich selber irgendwie die, ich weiß gar nicht, wie ich das übersetzen soll,

die Advanteste, die fortschrittlichste Open-Source-Datenbank.

Gut, Oracle und so hat wahrscheinlich noch ein bisschen mehr Funktionen.

Aber ja, tatsächlich wird meistens aber, wahrscheinlich aus Kostengründen,

tatsächlich jetzt so im Internetumfeld irgendwie dann meistens werden so Open-Source-Datenbanken verwendet.

Ja, ich habe schon mal gesehen, dass Leute Oracle verwenden, aber das ist eher selten.

Jetzt so bei, als Backend für Webseiten verwendet man normalerweise nicht Oracle, das ist halt auch einfach viel zu teuer.

Oder MSSQL-Server, doch, das gibt es tatsächlich Leute, die das als Backend für Webseiten verwenden.

Ein Beispiel einer populären Seite, die halt auf MSSQL-Server läuft, ist Stack Overflow.

Das ist auch faszinierend.

Ja, der war, ich weiß nicht, ob es der Gründer selber war, der war auch Produktmanager bei Microsoft, glaube ich.

Insofern, also die machen viel auf dem Microsoft-Stack und holen da unglaubliche Sachen raus.

Also die haben irgendwie ein halbes Rack oder, also das letzte Mal, gut, das ist jetzt auch schon lange her,

dass ich da irgendwie Artikel zu gelesen habe, aber das letzte Mal, dass ich das gelesen habe,

war Stack Overflow tatsächlich unter den Top Ten der traffic-stärksten Webseiten weltweit.

Und die haben dafür, Hardware war irgendwie so ein halbes Rack oder so.

Und das ist natürlich schon extrem beeindruckend.

Das ist überhaupt sowas, was halt wahrscheinlich viele Leute nicht wissen,

die jetzt wieder nicht so viel Erfahrung haben mit Datenbanken.

Die können echt wahnsinnig viel Dinge tun gleichzeitig und so.

Also man kriegt aus so einer ordentlich konfigurierten und getunten relationalen Datenbank

schon so mindestens ein paar tausend, vielleicht auch ein paar zehntausend Requests oder Statements pro Sekunde raus,

die die halt verarbeiten können.

Und dann kann man natürlich eine Menge machen.

Also vorausgesetzt der ganze Kram passt in den Hauptspeicher.

Aber man macht keine Dinge, die das irgendwie langsam machen.

Also es ist halt auch nicht so einfach, das zu optimieren.

Aber ja, genau.

Und das ist halt auch dieser Bereich der relationalen Datenbank.

Das ist halt der größte Datenbankbereich eigentlich.

Ja, vielleicht kommen wir dann, wollen wir zu dem praktischen Beispiel.

Ja, mit dem Beispiel, genau.

Das wäre super.

Wie macht man das jetzt alles und wie baut man das auf und warum?

Und was kann man damit so schönes machen?

Und was für Probleme könnten wir darüber stolpern und sowas?

Ja, dann...

Nehmen wir doch mal an, wir wollen jetzt Amazon nachbauen.

Wir haben einen kleinen Buchhandel in der Garage.

Ja, und wir überlegen uns jetzt so...

Da liegen jetzt ganz viele Bücher auf dem Boden.

Und dann will irgendjemand bestellen.

Dann muss dann irgendjemand in die Garage laufen, gucken, wie ist denn jetzt der Titel?

Habe ich den?

Dann liegt ein Buch unter dem anderen.

Das wäre natürlich doof, wenn man erstmal alleine suchen muss.

Deswegen haben wir jetzt überlegt, ja, pass auf, wir schreiben das Ganze jetzt in eine Datenbank.

Wie fangen wir jetzt mal an?

Vielleicht reden wir kurz über das Schema, wie man sowas aufbaut.

Nochmal kurz.

Genau.

Also, man würde jetzt zum Beispiel eben die Mitteilinformationen über diese Bücher,

also sowas wie Titel, ISBN-Preis und so...

Autor.

Genau, würde man halt in eine Datenbank schreiben.

Durchschnittliche Anzahl von Buchstaben pro Seite.

Vielleicht, ja.

Was auch immer man da...

Man würde das halt in eine Tabelle schreiben.

Aber man würde jetzt möglicherweise schon nicht den Autor...

Wenn man jetzt den Namen des Autors mit...

in diese Tabelle reinschreibt, dann hat man unter Umständen

ein Problem, nämlich

wenn jetzt halt...

Der Autor sich umbenimmt, weil er heiratet oder so?

Ja, genau. Heiratet oder sonst

irgendwie seinen Namen ändert,

dann müsste man ja,

dann kann man natürlich irgendwie alle

Zeilen, in denen der Name drinsteht,

die ändern,

aber man kann ja auch Pech haben und

wenn das jemand von Hand macht, dann ändert er halt

das nur, weil er davon gehört hat, dass es jetzt

für dieses Buch geändert werden soll, das nur in einer Zeile

und lässt die anderen halt weg und dann hat man halt...

Wir könnten Suche und Ersetze machen und dann machen wir sowas,

dann machen wir für jedes Jahr,

das wir für Bestellung haben oder jeden Monat, eine neue Datenbank,

eine neue Tabelle und dann müssten wir einmal nach

drei Jahren oder sowas 36 verschiedene Dateien öffnen,

immer Suche und Ersetze ausführen und dann den Namen ändern.

Ist doch super, oder nicht?

Ich könnte sagen, dass das nah dran ist

an dem, was viele Leute tatsächlich machen, aber das

kann man auch eleganter tun in der Datenbank

und dann hätte man möglicherweise

nur einen sogenannten Fremdschlüssel

in der Spalte Autor

in der Büchertabelle

und dann würde man den Namen

des Autors halt von der Autotabelle ändern

und dann wäre das

automatisch in allen Zeilen

in allen Bücher

oder allen Zeilen der Büchertabelle, in denen das referenziert wird,

würde das

automatisch geändert werden.

Und dann brauchen wir ja noch eine andere Tabelle

Autorix, wo dann alle Autorinnen

drinstehen.

Ja, wäre auch eine Möglichkeit, genau.

Und

ich überlege gerade,

das ist jetzt natürlich

also Autoren, ein Beispiel,

ein anderes Beispiel wäre User, die jetzt auf der Webseite

irgendwas einkaufen wollen oder so, da gibt es

da würde man in der Bestellung halt auch

nicht den User selber irgendwie in jede Bestellung schreiben,

sondern halt irgendwie die ID

von dem User, der irgendwas

eingekauft hat und

im Grunde

also ja, das heißt Datenbank

Normalisierung, wenn man jetzt dafür sorgt,

erinnert so ein bisschen an

wenn man Software schreibt, nennt sich das Dry,

so Don't Repeat Yourself, also wenn man Software

schreibt, sollte man auch Funktionalität,

die man an mehreren Stellen verwendet, halt nicht an mehreren

Stellen implementiert haben, weil wenn man das an

einer Stelle ändert und fräst es halt an der anderen,

dann hat man halt

ja, einmal ist es dann inkonsistent

das Verhalten und ja,

man hat halt auch die Gefahr, dass

dass man Dinge, die man einmal gefixt hat, halt dann

nochmal auftauchen.

Das ist doch bestimmt schon ein, zwei Mal passiert, oder? Also mir hat das früher ständig passiert

und dann ist mir irgendwann aufgefallen, oh, ich mach

eine Funktion und dann macht man die Funktion und dann macht man einen Test

und dann ist es halt erledigt

sozusagen. Also

sollte man halt möglichst versuchen, Dinge, die man

so logik, die irgendwo ist, halt immer nur einmal

irgendwo stehen zu haben. Ist natürlich manchmal nicht so ganz einfach,

und das ist bei Datenbanken halt auch nicht, weil

das weist sich so ein bisschen mit anderen Anforderungen,

die man hat, wenn es halt schnell sein soll,

dann ist das manchmal etwas schwierig, weil

relationale Datenbanken, dann wenn man

halt viele Tabellen miteinander verknüpft, man nennt das halt

Join, ja, das heißt, man kann halt anhand von

diesen Verzweigungs-,

also Fremdschlüssel-Dingsies

kann man halt Tabellen aneinander

ketten.

Ja, verketten.

Man kann sich das vorstellen, man legt die halt sozusagen

nebeneinander, sodass halt die

Spalte mit dem Schlüssel übereinander liegt, ja,

sozusagen, und wenn man das mit vielen macht, dann werden die Abfragen

langsam. So ein bisschen wie an so einen Spielautomaten,

wenn ihr so einen einahmigen Banditen

habt, dann zieht ihr einmal dran, da sind ja so drei verschiedene,

und wenn ihr dann parallel so ein Alles-Zeit-Gewinn,

dann habt ihr den Schlüssel, den ihr braucht.

Dann hat man

die Zeile anhand von dem Schlüssel irgendwie

zusammengeführt, ja, genau.

Und, äh,

ja, ähm,

also, ähm, also das ist halt auch, wie man

ein Schema designt und so, das ist halt so ein bisschen

Kunst, und man braucht Erfahrung dafür,

ähm,

ähm, aber man kann halt sagen, ja,

man sollte das so ein bisschen normalisieren, also

meistens gibt es dann ganz viele unterschiedliche Normalformen,

und meistens die Formen,

die man dann so hat, ist so irgendwas zwischen dritter

und vierter Normalform, oder so,

zwischen dritter und Boy-Scout-Normalform, oder sowas,

aber ich möchte gar nicht so sehr im Detail darauf eingehen,

was jetzt die Unterschiede zwischen den Normalformen sind,

also irgendwie kann man sich auch durchlesen auf Wikipedia,

oder so, braucht man auch im Alltag eigentlich gar nicht

zu wissen, sondern da hat man dann halt irgendwann

ein Gefühl dafür, wenn

ein Datenbankschema okay aussieht,

und dann macht man das halt so

Das heißt, ich gehe tatsächlich erstmal hin

und nehme ein Whiteboard,

einen Zettel, und schreibe mir auf, wie die Daten

aussehen sollen. Ja, ja, tatsächlich, also

wenn ich irgendwie

einen Datenbank designe für irgendein Projekt, dann

nehme ich mir einen Zettel, und

fange an, Entity-Relationship-Diagramme

zu malen, so nennt man die.

Was passiert denn später, wenn ich während

dem Projekt merke, hey, ich habe aber die und die

Daten vergessen?

Bastel ich da einfach irgendwo rein, ergänze ich dann dieses Schema

einfach, oder? Ja,

das kommt darauf an, was das dann für eine Änderung ist,

also das ist ja auch so ein Problem,

man kann

Datenbanken

nicht so richtig super ändern,

also, relationelle Datenbanken,

das Schema lässt sich schon ändern,

aber das ist halt so ein bisschen

knifflig, und wenn man das tut, muss man halt

irgendwie aufpassen.

Dass alte Datenbanken noch kompatibel sind, oder sowas?

Ja, dass

man das so ändert, dass nicht

irgendwelche Inkonsistenzen entstehen, und auch

das halt... Wie wäre das jetzt bei unserem

Beispiel, beispielsweise?

Also, wenn ich mir jetzt überlege, ich brauche

jetzt eine neue Spalte in dieser Büchertabelle,

ja, weiß ich nicht, es gibt jetzt nicht nur

die ESPN...

Jemand, oder das Genre, oder sowas,

jemand sammelt Seefahrerbücher.

Eine Kategorie, da würde ich halt tatsächlich, also

das, was man sich zuerst überlegen könnte, ist, man macht

einfach ein Textfeld

oder Charfield,

das halt den Kategorienamen

enthält,

und dann hat man halt das Problem, okay,

dann stellt man fest,

oder am besten noch, okay, fangen wir so

an.

Man schreibt halt, man nimmt Text

statt Kategorie

und sagt jetzt,

okay, alle Texts, also weiß ich nicht,

Politistik,

Seephara-Roman, oder

schreibt man jetzt, Komma separiert

halt in eine Spalte rein,

dann hat man damit die erste Normalform verletzt.

Und man muss sich dann im nächsten

Schritt, wenn man das halt weiter normalisiert, überlegen,

okay, nee, das geht nicht, darf ich so nicht machen?

Also der eigentliche Grund,

warum man das nicht so machen sollte, ist halt, dass es die

Anfragen halt schwierig macht und dass man

es auch sehr schlecht ändern kann und dass, wenn man

was ändert, kann man Sachen kaputt machen,

weil

Inkonsistenzen entstehen können und so.

Dann zieht man erst mal diese Dinge

auseinander und sagt halt, okay, nicht in

einer Spalte

mehrere Texts reinschreiben, sondern

dann hätte man sozusagen eine

N-zu-M-Relation, also nicht nur, wo ein

Fremdschlüssel in der einen Tabelle zu einem Fremdschlüssel in der anderen Tabelle

passt, sondern man hat dazwischen den Link,

man hat jetzt einmal Text als Relation

und einmal halt die Bücher als Relation

oder als Tabellen halt und

dazwischen hat man jetzt noch eine Link-Tabelle

oder eine Link-Relation zwischen

Büchern und Text, sodass man

mehrere, also für jedes Tag hätte man dann sozusagen

einen Eintrag in der Link-Tabelle,

wo dann drin steht,

ID von diesem Buch, ID von

diesem Tag, ja, und das ist dann halt sozusagen

die Verbindung

zwischen den beiden Tabellen, sondern halt

eine Tabelle mit allen Texten, die ist möglicherweise gar nicht

so lang, es gibt vielleicht nur 1000 Texte oder so,

und

vielleicht ein paar Millionen Bücher und

jetzt hat man halt eine Link-Tabelle, die

wahrscheinlich dann irgendwie ein paar 10 Millionen Bücher

oder ein paar 10 Millionen

Zeilen oder so lang ist, wo halt

jedem Buch ein paar Texte

zugewiesen werden. Und dann

ist es alles wieder schön in einer Normalform und

das kann man dann auch wieder nett abfragen.

Ja,

wenn man dann aber

quasi diesen Text halt,

wenn man diese Texte jetzt aber betrachtet

als Blätter in einem Kategorienbaum oder

so, dann wird es wieder so ein bisschen schwierig,

weil dann versucht man etwas in einer relationalen Datenbank

abzuspeichern, was gar nicht so gut geht, nämlich

irgendwie so Baumstrukturen oder

Grafenstrukturen.

Das kann man dann auch machen, und wenn es

nicht viele Texte oder Kategorien sind,

dann würde man versuchen, das wahrscheinlich in erste Z

nehmen.

Das ist, kann man sich mal angucken,

wenn einen das interessiert, wie das, dann kann man

dann halt auch per SQL Abfragen machen, wie

ja, welche Bücher liegen denn jetzt

unterhalb von dieser Kategorie.

Was man macht ist, man schreibt dann jede,

man hat so eine Kategorie in Baum und man schreibt

dann an jede, jedes

Element in dieser hierarchischen

Struktur, den travisiert man einmal

First Order, ich weiß

gar nicht genau.

Und also beim

Durchlaufen nummeriert man jeden Knoten,

an dem man vorbeiläuft, durch

und man hat eine Spalte links und

eine Spalte rechts und links,

wenn man links an den Sachen vorbeiläuft

in den Baum, schreibt man halt die

Nummern links rein und dann rechts, wenn man

rechts dran vorbeiläuft und dann kann man so Sachen

Range-Abfragen dazwischen machen

und magischerweise führt das dann dazu, dass man

so Subbäume rausselekten kann und so.

Aber das ist dann halt schon so wirklich fortgeschritten.

Und im Endeffekt,

wenn man jetzt große

Grafenstrukturen hat oder Bäume,

dann wäre es wahrscheinlich besser, das gar nicht mehr in der

Relationalen Datenbank zu machen, sondern das irgendwie

in einen anderen Service zu packen.

Ja, und da sind wir schon,

boah, das ging aber schnell, da sind wir schon an Grenzen,

wenn man das in der Relationalen Datenbank gut machen kann.

Ja, also das Dorfschachtrekarat ist mittlerweile

rausgewachsen, also wir können die ganzen Bücher dann

in der Garage nicht mehr lagern.

Nee, nee, nee, Moment, Moment, wir sind noch nicht, also was eigentlich auch,

nee, wir sind noch nicht

so weit, wir sind noch immer bei der ganz normalen, einfachen

Datenbank, würde ich sagen.

Ja, also das,

wofür wir die nämlich auch brauchen, die Datenbank,

ist halt so Transaktionen-Prozessen,

wenn jemand was kauft zum Beispiel. Oh, jemand hat bei uns

eine E-Mail geschickt, hat gesagt, hey, habt ihr das Buch da?

Und wir gucken nach, sagen ja,

können wir dir schicken. Dann, ja,

bitte an die und die Adresse und so, dann machen wir so ein Paket,

machen da so ein Stempel drauf und sagen, hey,

hier bitte dein Buch.

Ja, und dafür, dass das gut

funktioniert, dann müssen halt auch einige Sachen

für gewährleistet sein und

das ist halt zum Beispiel so etwas wie,

naja, wenn ich halt ein Buch kaufe, dann muss ich irgendwie

sicherstellen, dass das im Lager ist. Das heißt, wenn

jetzt ich ein

Buch verschicke, dann sage ich meiner

Datenbank irgendwie so, okay, jetzt

ist davon eins weniger da im Lager.

Aber wenn jetzt auf der Webseite jemand sagt, ich würde

dieses Buch einkaufen, dann muss halt gewährleistet

sein, dass das halt noch da ist. Das heißt,

ich brauche halt eine zentrale

Stelle, in der die Wahrheit... Ihr fällt direkt

wieder eines der Probleme ein.

Zwei Leute wollen das gleiche Buch haben,

was nur noch einmal da ist und die wollen gleichzeitig eins

kaufen. Genau, das ist halt

eine problematische Geschichte.

Aber wenn man jetzt eine Datenbank hat,

die

sozusagen Wahrheit kennt und alle

nur auf die zugreifen, dann

kann im Grunde nichts passieren. Also da können

keine Konflikte auftreten,

weil in dem Moment, wo jemand auf kaufen klickt

auf der Webseite und es noch ein Buch da

war...

Die Frage ist halt jetzt, was

man macht, wenn viele Kunden sich immer so ein Buch

angucken, das in ihren Warenkorb reintun,

weil sie es kaufen wollen, aber 90%

dieser Kunden einfach gar nicht am Ende kaufen,

sondern irgendwie wieder abspringen, weil die dann sagen, naja, doch nicht.

Und dann hätten

jetzt ja alle sich bei sich in den Warenkorb reingelegt und

wenn nur noch eins da ist, vielleicht hätte

der Zweite direkt angezeigt bekommen, gibt gar nichts, der ihn wirklich

gekauft hätte.

Also was natürlich passieren kann, ist, dass dir angezeigt wird,

es gibt noch ein Buch, obwohl es keins mehr gibt.

Weil du sitzt

halt vor der Webseite und

machst nichts.

Oh, leider war jemand schneller und hat vor zwei Sekunden...

Genau, du kannst, sobald du draufdrückst, in dem Moment,

wo sozusagen diese

Bestelltransaktion gestartet wird und dann

in der Datenbank aber die Bedingungen,

es muss mindestens eins im Lager sein, damit

die Bestellung ausgeführt werden kann, nicht mehr erfüllt ist

und diese Constraint wird verletzt,

dann sagt die Datenbank so, geht

nicht. Und dann kann man ihm so eine

Fehlanwendung anzeigen und sagen so, oh ja, tut uns leid,

das hat nicht geklappt, kein

Buch mehr auf Lager.

Das ist ja im Grunde okay.

Ja, gerade so.

Ja, also was halt

blöd wäre, ist, wenn man dem User sagt,

okay, du hast das jetzt bestellt,

und dann sagt er am Schluss so,

äh, du kriegst doch kein Buch, weil

war keins mehr da. Das ist dann halt so ein bisschen blöder.

Ist aber eine Situation, die dann später, wenn wir halt

nicht mehr auf einer Datenbank bleiben können,

weil das einfach

von der Skalierung her

nicht mehr klappen kann irgendwann,

dann kommen wir in solche Situationen rein

und da müssen wir uns dann überlegen, wie wir damit umgehen.

Aber solange das alles auf einer Datenbank läuft,

ist das

im Grunde kein Problem, kann man das sauber lösen.

Ich hatte ja, so mal es war,

ich hatte das vielleicht schon mal kurz erwähnt, bei einer Bank.

Ich habe eine Transaktion gemacht, da hat dann

die Bank gesagt, ja, ist wunderbar, dein Überweisung wurde

vernünftig ausgeführt, und dann

zwei Wochen später

kriegte ich dann so eine Mahnung, und dann habe ich noch mal

aufs Konto geguckt, und die Transaktion war weg.

War nicht da. Was war, habe ich dann da angerufen,

haben gesagt, oh, ja, also in irgendeiner Logfile

stand das dann wohl noch drin, dass ich so eine Transaktion eigentlich

gemacht hatte, die aber nicht ausgeführt worden war.

Das war ein bisschen blöd dann für mich, aber

ja, scheint wohl auch mal so

ein, ja, also

möglicherweise war das eben eine Bank,

und das ist tatsächlich bis, ich weiß nicht,

vor gar nicht allzu langer Zeit

tatsächlich üblich gewesen, wo dann

die Transaktionen nicht

in einer relationalen Datenbank

direkt ausgeführt werden, sondern

wo es dann Batch-Prozessen gibt,

nachts. Also die Sparkassen haben das

lange gemacht.

Man schmeißt dann manuell die ausgedruckten

Briefchen ins Überweisungs...

Lochkarten. Fährt jemand mit den

Lochkarten dahin, und dann kommen die in so einen Laser, und dann werden

die da durch, und vielleicht, wenn dann eine Lochkarte rausfällt,

dann ist halt eine Transaktion weg. Nicht so gut.

Ja, aber kann, sowas kann tatsächlich

passieren, und das ist natürlich etwas,

was ja gerade bei der Bank eigentlich, wenn man sich

denkt, na, sollte eigentlich nicht. Aber, ja,

aber wenn man

ein sauberes, relationales Datenbanksystem

verwendet, dann

kann das

eigentlich nicht, oder sagen wir so, das bietet einem

Lösungen für dieses Problem, und

im Grunde, wenn

das Ding sagt, ja, die Transaktion ist durch, dann

hat das auch funktioniert. Man kann sich auch darauf verlassen.

Ja, und auch

davon an, welche Daten man verwendet.

Es gibt halt welche, die nicht so richtig

alle Features unterstützen, die man dafür braucht.

Also, zum Beispiel,

was man eigentlich dafür braucht, damit das ordentlich

funktioniert, ist,

man braucht halt Isolation

zwischen unterschiedlichen

Transaktionen. Also, Transaktion heißt eigentlich

nur,

dass man mehrere Schritte,

die man ausführt,

irgendwie zusammenbündelt,

und dann halt entweder alle

funktionieren, oder keiner.

Ja, und das wäre halt

genauso ein Fall, wie, ich kaufe

ein Buch, ist halt ein Ding, in der Datenbank

müssen jetzt mehrere Sachen passieren. Da muss halt

irgendwie,

diese Bestellung muss erzeugt werden, dann muss

irgendwie aus dem Lagerstand

irgendwie

rausgelöscht, muss halt

der Lagerbestand um eins reduziert werden,

und so, und das sind halt

mehrere Statements, die ausgeführt werden.

Und jetzt müsste halt,

wenn

jemand anders in der Zeit

das gekauft hat, und es

dieser Bücher mehr auf Lager gibt,

müsste halt dann

nachdem

der eine Teil der Transaktion, nämlich

das Reduzieren

des Lagerbestandes

von diesem Buch nicht mehr funktioniert,

müsste halt auch das andere, nämlich das Erzeugen der Bestellung,

auch fehlschlagen, und dann halt eine Fehlermeldung

zurückkommen. Und dann ist es halt sauber.

Wenn ich jetzt ein System habe,

das das nicht macht, und ich

erzeuge die Bestellung, habe jetzt in meiner Bestellung

eine Tabelle, das Ding erzeugt,

sag jetzt in der

Lagerstandstabelle

dieses Buch eins weniger, und dann sagt das,

hier habe ich eigentlich von Strand auf, es darf nicht

weniger als null werden, also minus eins Bücher

ist schwer, das funktioniert irgendwie

nicht so richtig, dann sollte

und es dann knallt,

dann kann das natürlich,

wenn ich jetzt ein System habe, das keine Transaktion kann,

dann hätte ich jetzt die Bestellung zwar immer noch da,

aber...

Was ist denn jetzt als Beispiel, wenn ich jetzt sowas habe wie minus ein Buch,

und ich möchte jetzt einfach, dass wenn

minus ein Buch ist, dass das nachbestellt wird von

dem Händler um die Ecke, also

der hat noch eine Garage nebenan, ist noch ein Händler,

der hat auch so Bücher, und vielleicht hat der eins

da, und dann sage ich einfach, ja, ich muss das irgendwo anders herbekommen.

Könnte ich ja auch wollen.

Kann man auch machen,

müsste dann, ja, das hängt dann vom System ab,

was die Logik dann macht. Man könnte ja sagen,

okay, die Bestellung wird trotzdem ausgeführt, dafür wird dann aber

das... Oder das Buch wird gedruckt oder sowas, ne?

Ziel, wann das... Ja, genau,

wenn normal produziert,

aber dann verändert sich möglicherweise das Ziel dafür, wann es halt

ausgeliefert wird, oder so, ne?

Und das ist halt dann, je nachdem, wie das System

funktioniert, kann man das machen.

Okay, also ich habe am Anfang mir so ein Schema ausgedacht, wo dann halt drinsteht,

was ich überhaupt alles machen will, machen kann,

und wenn mir irgendwelche neuen Dinge einfallen,

oder so, dann muss ich kurz

überlegen, was

nicht an meinem Schema endet, aber

am besten mache ich das Schema am Anfang schon so

fertig, vollständig, dass das

unproblematischer geht. Das ist halt,

das ist ein bisschen ein Problem, man sollte ein Schema

schon von Anfang an halbwegs so designen,

dass es halt passt, das ist

später nicht mehr so ganz einfach, das zu ändern,

man kann das natürlich ändern, aber

das ist auf jeden Fall...

Ja, aber das hängt ja ein bisschen vom Geschäftsmodell ab, ne?

Wenn ich jetzt auf einmal merke, so, oh, ich verkaufe

jetzt vielleicht gar keine Bücher mehr, sondern,

weiß nicht, kompliziertere Produkte, oder so was,

die noch einen anderen Aufwand haben, die jetzt nicht nur getaggt

werden sollen, sondern wo noch mehr

Metainformationen drin sind, irgendwelche

anderen Snippets, also der Buchtext vielleicht

noch, oder andere

Informationen, die dazugehören, oder so,

dann wäre das ja notwendig.

Ich kann ja nicht jedes Mal einen Neudankmann anfangen, sondern ich muss ja auch

gucken, dass die irgendwie mit skaliert.

Aber das sind wirklich schwierige Probleme,

das ist ein bisschen unintuitiv,

dass das so knifflig ist,

aber es ist leider so. Ein wirklich

lustiges Beispiel aus der Praxis,

das zeigt, dass

es halt nicht so einfach ist, möglicherweise

ist, finde ich, iTunes,

der App Store,

und der App Store war am Anfang,

man hat den nicht neu entwickelt, sondern das war,

man hat den, also über iTunes

konnte Apple ja schon immer irgendwie so Musik verkaufen,

das hat auch recht gut funktioniert,

oder halt deutlich früher,

als es jetzt das iPhone gab und

den App Store, und dann

sollte es halt dieses App Store Feature geben,

und dann haben sie halt einfach ihr

iTunes-Song-Verkauf-Ding genommen,

und das halt einfach nur gesagt,

okay, das sind jetzt keine Songs, sondern das sind Apps.

Was halt dazu führt, dass bis heute,

und jetzt sind wir mehr als 10 Jahre später,

bis heute

haben halt irgendwie Apps einen Titel

und eine Länge, Songlänge oder sowas,

was halt totaler Quatsch ist, das passt ja überhaupt

nicht zusammen, aber es ist halt sehr, sehr

schwer, das zu ändern, weil,

ja, das würde so viel Logik

irgendwie brechen,

dass in anderen Systemen,

das ist halt extrem, also

du kannst halt, ja,

also eine solche Migration durchzuführen, ist halt hinterher

sehr, sehr schwer, und

also quasi die ganzen Daten einmal anfassen und

abgleichen und bereinigen und schrubben und putzen.

Die Daten sind gar nicht so sehr das Problem,

das Problem sind die anderen Systeme,

die es auch alle drumherum gibt, die sich verlassen,

dass die Datenbanken so aussehen, wie sie aussehen.

Also wenn ich jetzt, also die Daten selber zu ändern,

ist, glaube ich, wäre nicht so das Problem,

weil ich muss jeden Prozess bei jedem Nutzer dieser Datenbank

darüber informieren, dass er sich das Schema...

Und der muss damit klarkommen, und das

ist halt möglicherweise Legacy-Code,

der letzte, der sich damit auskannte,

vor fünf Jahren gegangen ist, aber

das System macht irgendwas Vitales, was irgendwie

total wichtig ist für das

Business, und, tja, dann

wird es halt richtig schwer, und wenn du dann nicht nur

ein solches System hast, sondern zig,

dann kann es sein, dass du halt zehn Jahre lang das nicht mehr ändern kannst.

Manchmal

sieht man dann so ein bisschen lächerlich aus, aber

wie jetzt in dem Apple-Fall,

wenn man keine Songlänge hat,

ja, aber

es ist halt, das zeigt halt so ein bisschen,

wie knifflig das dann werden kann,

wenn man Pech hat.

Ja,

und das ist auch so ein Problem bei

relationalen Datenbanken insgesamt,

möglicherweise, würde ich sagen, also

gerade der E-Commerce-Fall oder der Amazon-Fall

funktioniert eigentlich ganz gut,

zunächst, also später wird das dann halt auch

nochmal ein bisschen problematischer, aber weil

physische Dinge

halt

relativ stabil sind, was irgendwie so ihre

Eigenschaften angeht. Also, da funktionieren

relationale Datenbanken halt besonders gut.

Unwahrscheinlich, dass so ein Buch noch ein anderes

Kappa enthält, oder sowas.

Also, dass sich Bücher jetzt irgendwie,

dass die plötzlich ein Attribut bekommen, was

es halt vorher nicht gab. Die wachsen Flügel.

Die haben halt irgendwie Titel, Seitenanzahlen, oder sowas,

aber dass jetzt plötzlich irgendwie, keine Ahnung,

ich weiß nicht, was man sich da

vorstellen könnte, man müsste jetzt irgendwie

Bücher...

Jedes Buch enthält einen Geist,

Bücher haben Flügel,

ja, keine Ahnung,

Bücher kann man jetzt essen, oder so, haben einen bestimmten Geschmack.

Das ist sehr unwahrscheinlich, dass das passiert, weil

das würde bedeuten, dass sich die physikalische

Realität irgendwie ändert, was sie ja

natürlich auch tut.

Aber das tut sie relativ langsam.

Und das ist gut,

weil das können relativ,

wenn man jetzt sozusagen diese

physischen Dinge in der Datenbank beschrieben hat, die kann sich

auch nur langsam ändern. Und das passt dann so ein bisschen

zueinander. Also, das ist halt, wenn man

jetzt die Eigenschaften von einem Buch erstmal erfasst hat, dann ändert sich

da wahrscheinlich nichts.

Da ist wahrscheinlich in den nächsten 20 Jahren nicht mehr so wahnsinnig viel dran.

Und da muss man auch in der Datenbank nicht so wahnsinnig viel ändern.

Wenn man jetzt ein anderes

Problem hat, und man jetzt

zum Beispiel in der Datenbank nicht Daten

über physikalische Objekte hält,

sondern Daten über Daten.

Oh, Metadaten.

Metadaten.

Die können sich dummerweise

unter Umständen, je nachdem wie...

Daten über Daten über Daten.

Ja, da kann plötzlich die

Geschwindigkeit, mit der sich die Strukturen da ändern

müssen, deutlich schneller

werden. Und dann wird es schwierig. Dann sind relationale

Datenbanken auch so, das ist dann ein Problem.

Das ist auch möglicherweise einer der Gründe dafür,

warum jetzt in letzter Zeit halt immer mehr so

NoSQL oder

Dokumentdatenbanken

oder

wenn man das, manche nennen das auch

Schema-less, warum die halt

populärer werden, weil man damit

halt möglicherweise auf diese geänderten Anforderungen

halt besser reagieren kann, dass man

ja, möglicherweise ad hoc

das Schema irgendwie ändern muss und das halt

in der relationalen Datenbank nicht so ganz einfach ist.

So absolut kann man das auch nicht sagen. Also es gibt

da diverse Möglichkeiten, wie man die

Geschichten miteinander verbinden kann und

ja,

wenn Schema-less ist, halt auch nicht

Schema-less, sondern das bedeutet halt mehr oder

weniger nur, dass das Schema jetzt implizit

in deiner Applikation ist und du halt

immer aufpassen musst, wenn du deine Applikation änderst, dass du

da das Schema nicht kaputt machst oder änderst oder so

und das überlegen sich viele Leute

dann nicht so richtig und dann ändern sie irgendwas. Dann passieren

furchtbare Dinge und

dann fällt ihnen auf, dass sie doch ein Schema haben.

Und ja, dass sie dieses Problem halt doch nicht

losgeworden sind. Also

es ist leider alles nicht so einfach und

das ist

tatsächlich so, dass man bei

Datenbanken halt im Design

am Anfang ein bisschen mehr Arbeit hat, aber dafür

hat man auch dann einen lustigen Vorteil,

nämlich, ja, es ist immer so schön, irgendwie

Daten

altern wie Wein, ja, also wenn man halt

viele gute Daten hat, das ist super und wenn

das mehr werden, das ist immer schön und das altert auch

gut, ja, das wird immer besser mit der Zeit.

Man kann immer mehr Wissen daraus generieren,

man kann immer mehr Fragen beantworten oder so,

das ist eine sehr schöne Sache und

Applikationscode,

Altert wie Fisch,

ja, also das ist

nicht gut, wenn immer Features drankommen

oder Sachen geändert werden, also das wird immer

schlimmer mit der Zeit. Das ist eigentlich selten

so, dass man irgendwie jetzt mehrere Jahre

irgendwie ein Projekt entwickelt und die Codequalität

wird immer besser. Das ist irgendwie

nicht so, sondern es wird immer,

es wird irgendwie, und daher ist halt

noch ein Frickel da, noch ein Frickel dort,

kleines Modülchen an der Seite,

und auch das Problem ist halt, die Anforderungen

verschieben sich halt irgendwie

oder, sagen wir mal so, die Realität

ändert sich und dann ist halt

der ursprüngliche Plan oder die

ursprüngliche Architektur der Applikation ist halt

nicht mehr darauf angepasst und so

und da hat man

dann halt, ja, genau

dieses Problem,

dass, wenn man jetzt das Schema verlagert

in die Applikation und die Applikation aber

altert wie Fisch, dann halt man halt auch, ja,

dann altern auch die Daten nicht gut und

deswegen ist es eigentlich schon sinnvoll, eine Trennlinie zu haben,

um zu sagen, okay, selbst wenn wir die

Applikation irgendwann wegschmeißen müssen,

neu schreiben müssen oder so, dann haben wir immer noch

die Daten und die sind halt sauber

strukturiert und das sieht alles gut aus

und das kann eine sehr wertvolle

Sache sein, wenn man das richtig macht

und, ja,

genau,

deswegen ist diese Trennung,

wo man halt irgendwie strikte,

ein striktes Schema hat und das

auch diverse Constraints,

die halt irgendwie, also dass man halt solche Sachen drin hat,

wie es kann nicht im Lager

Sachen geben,

mit einem Lagerstand von Minus irgendwas,

das darf halt nicht sein, da ist ein Fehler passiert

und kann die Datenbank schon dafür sorgen,

dass das halt nicht da reingeschrieben

wird, weil die sagt halt so, nee, so nicht,

man muss halt bloß dieses Constraint definieren und sagen, so,

auf dieser Spalte, da dürfen keine negativen Werte

auftauchen oder eben sowas wie ein Gehalt,

das darf auch nicht negativ werden oder

das halt

bestimmte Datumsinformationen halt nicht

so und so sein können,

ja,

oder

dass man halt,

tatsächlich, auch

was man mit Postgres machen kann, Postgres ist halt

wirklich eine schöne Wahl für, wenn man jetzt mit so einer

Geschichte anfängt,

das kann so tolle Sachen wie,

wenn wir jetzt,

um in diesem Buchhandelsbeispiel zu bleiben,

du hast jetzt eine Büchertabelle,

da sind natürlich auch alte Bücher drin, weil die werden ja auch

möglicherweise referenziert

von Bestellungen, die

lange

zurückliegen oder so, du möchtest aber,

wenn du jetzt eine Suche irgendwie auf der

Website hast oder du hast halt irgendwie

so eine Facette Navigation, wo

du nach Kategorien einschränken kannst

und da klickt jetzt ein User drauf

und sagt, okay, ich hätte jetzt da gerne

Romane oder Seefahrer-Romane,

dann

gibt es einen Index, der das halt schnell macht,

diese Abfrage und du willst jetzt

aber Sachen von diesem Index ausschließen,

zum Beispiel Bücher, die es gar nicht mehr gibt,

die nicht mehr produziert werden, die vor Jahren

irgendwie nicht mehr, seit Jahren nicht mehr gedruckt

werden und das kann man mit Postgres tun, man kann

dann sagen so, also

ich brauche diese Einträge,

in der Buchtabelle noch, um halt,

damit die referenzielle Integrität, so nennt man das

halt, von alten Bestellungen nicht bricht,

die ja brechen würde, wenn ich

zu einfach löschen würde, dann hätte ich

halt einen Pointer in der Bestellungstabelle,

der halt auch etwas zeigt, was es nicht mehr gibt,

das wäre schlecht, weil ich dann gar nicht mehr

weiß, was es sein soll und so,

aber trotzdem werden diese Dinger

nicht mehr in den Index geschrieben, also

ich kann halt den Index so definieren, dass er nur

Sachen,

Bücher mit reinnimmt,

die halt auch tatsächlich noch verkauft werden,

und das heißt, das ist nicht so,

und an solchen Stellen ist Postgres halt sehr schön,

hat sehr viele Features,

zum Beispiel jetzt im Unterschied zu MySQL, wo das

halt so, solche Sachen gehen da gar nicht, also das

halt, und da hast du dann halt ein Problem, wenn du ganz,

bei Büchern ist es jetzt nicht so schlimm, also

so viele Bücher gibt es nicht und

so viele, die dann halt nicht mehr

verkauft werden, auch nicht, aber man könnte sich

vorstellen, es gibt durchaus Anwendungen, wo man dieses

Problem ganz massiv bekommt, dass man halt

eine Menge gelöschte Geschichten in der Tabelle hat,

die man aber nicht wirklich löschen kann, sondern nur als gelöscht markiert,

und dann der Index aber,

immer größer wird und langsamer wird, weil

ja, man halt nicht so einen partiellen

Index über Sachen haben kann.

Ja, überhaupt, Postgres kann

halt auch noch diverse andere Geschichten, damit könnte man halt auch so Sachen

lösen, wie, welche Pakete kriege ich

eigentlich in so einen Lieferwagen rein und so, weil

der kann halt, das Ding kann halt nicht nur

so B-Trees, die man

jetzt für

Textabfragen,

Indexabfragen benutzt, also dass man sagt,

welche

Kategorie beginnt jetzt mit folgenden drei Buchstaben

oder so, da nimmt man B-Tree, aber

es kann halt auch solche Sachen wie Polygone,

Abmessungen,

überdeckt das eine das andere,

es kann halt so

A-Trees, die man halt für diese ganzen

räumlichen Datengeschichten braucht,

aber es kann nicht nur das, sondern es kann auch so Sachen wie,

welche Sachen liegen nah an anderen, so

KD-Trees, Brawl-Trees,

es kann sogar Suffix-Trees, also

Postgres kann da eine ganze Menge unterschiedlicher

Abfragen und Indizes,

die man, also

Aber ich glaube, die lohnen sich jetzt noch nicht bei unserem

kleinen Laden, wir sind ja glaube ich noch,

Doch, doch,

Ja, ja, wenn du

deine Lagerhaltung,

das möchtest du im gleichen System machen, damit

du nicht das Problem kriegst,

dass du den Start-State zwischen

unterschiedlichen Systemen synchronisieren musst, also wenn du

jetzt deine Lagerhaltung in einem System machst und

machst dann deine Webseite

oder die Datenbank, die die Webseite

betreibt,

sozusagen, über die du

Bücher verkaufst, wenn das unterschiedliche Systeme sind,

dann musst du den State zwischen diesen Systemen ja

irgendwie synchronisieren.

Was

schlecht ist, würde ich zum Beispiel sagen,

das ist halt am Anfang

sehr, sehr hilfreich, wenn das alles ein System ist,

weil man dann eben

tatsächlich eben die referenzielle Integrität,

Constraints, über alle Daten

hinweg machen kann und dann von der

Datenbank sicherstellen lassen kann schon, dass

bestimmte Sachen nicht gehen und dass bestimmte

Sachen immer erfüllt sein müssen.

Das heißt, unser Schema setzt das dann tatsächlich fest und das

kommt dann sonst direkt ein Fehler aus der Datenbank, hey,

nur dürfen wir nicht, geht nicht und wir haben das Schema

dabei erarbeitet in unseren kleinen Laden und so sollten wir dann

Und dann kann dann die Applikation oder die Programmierer

die jetzt vielleicht gar nicht,

die Leute, die die Webseite bauen, die haben jetzt

vielleicht gar nicht so viel Ahnung von Lagerhaltung,

die können aber, egal was sie auf der Datenbank machen, sie können nichts

kaputt machen, weil wenn sie etwas

tun, was eigentlich nicht geht, wie zum Beispiel

einen Lagerstand von hoch auf minus eins setzen,

dann sagt ihnen die Datenbank, ne, mach ich nicht.

Und dann kriegen sie halt einen Fehler. Und das ist

halt sauber, weil wenn du jetzt zwei Systeme hättest

und musst jetzt da synchronisieren

und jetzt ist aber schon irgendwie was Blödes passiert.

Der Datenbank steht jetzt minus zwei Bücher und dann

sagt die eine Datenbank, du sagst aber eigentlich nicht, dann sagt die

eine Datenbank, ja, hab ich aber. Und dann, ja, okay.

Da kommst du halt in Teufels Küche.

Also man könnte sich vorstellen, dass das eine gute Idee wäre,

weil das macht, dann wird man halt relativ schnell feststellen,

ist keine gute Idee, ist doof.

Das ist auch vielleicht ein bisschen unintuitiv,

aber ja. Und natürlich,

nachher muss man Sachen funktionierender

rausnehmen und man muss dann das

in mehrere Systeme aufkleinern. Man sollte so lange wie möglich

versuchen zu verhindern, dass das passiert, weil

das macht alles viel, viel schwerer.

Ja.

Genau.

Also wo sind wir jetzt eigentlich genau?

Klein und niedlich, wir haben

Postgres, machen alles

über Postgres, wir haben noch ein bisschen JavaScript

auf der Client-Seite, ansonsten

nehmen wir, sagen wir mal, Django oder so

als Web-Framework.

Also genau, jetzt kommen wir erstmal zu

wie machen wir jetzt Python?

Genau, da brauchen

wir halt irgendeine Art, wie wir auf die Datenbank

zugreifen.

Üblicherweise, wie man

Statements oder Abfragen an eine Datenbank formuliert, ist halt

SQL, heutzutage halt so der Standard

für solche Systeme.

Aber das ist halt immer ein bisschen Fremdkörper.

Code schreiben und dann hat man jetzt so ein

SQL-Statement. Das passt von der Syntax her

überhaupt nicht in Python rein. Da muss man einen langen String

machen, der irgendwie vernünftig aussieht und

da muss dann alles stehen, was mit der Datenbank reden kann.

Genau, und das ist halt irgendwie

nicht so schön. Also das gibt dann unterschiedliche

Methoden. Wenn man jetzt

tatsächlich mit den rohen Statements arbeitet, es gibt Leute,

die packen halt alle Statements in

ein File und packen dann

Funktionen drum und dann ruft man halt diese Funktionen auf.

Das kann man machen, das hat so

Vor- und Nachteile. Dann kann man aber auch sagen,

okay, das ist aber schlecht, eigentlich möchte ich

in dem Moment, wo ich mit den Daten arbeite, das Statement

auch sehen und auch ändern können. Dann

packt man halt sozusagen die Statements

immer an die Stelle, wo man halt

tatsächlich mit den Daten arbeitet. Das hat

auch wiederum Vor- und Nachteile. Das hat den Vorteil, dass man halt

Sachen leicht ändern kann. Das hat den Nachteil,

dass man unter Umständen mehrere Statements,

die sehr ähnlich oder gleich sind, an

unterschiedlichen Stellen hat.

Alles nicht so total toll.

Auch nicht so ein einfaches Problem.

Und eine

ganz gute Lösung für dieses Problem

sind so

objektrelationale Mapper

oder ORMs.

In Django ist einer eingebaut.

Der Django ORM.

Ja, genau. Wo man dann halt

gar nicht wirklich mitkriegt,

dass das SQL unten drunter ist, sondern

man schreibt halt ganz normale

Python-Code.

Man definiert

die Daten, die man in der Datenbank stehen haben

möchte, einfach nur als Klassen.

Das heißt, das Schema wird nochmal

als Klasse eingebaut, oder?

Das Schema entsteht dadurch,

dass man unterschiedliche Klassen

hat, die irgendwie in Beziehung zueinander stehen.

Also, was aufeinander neppt,

ist halt Klasse und Tabelle.

Also, ich hätte dann, wenn ich Bücher kaufen möchte, halt eine

Klasse Book.

Und dann hätte ich halt vielleicht eine Klasse

Tag. Und

wir hatten das ja eben mit dem Beispiel, ich habe eine

N-zu-M-Beziehung zwischen Tags und

Büchern. Und dann würde man

entweder in Tags oder in Büchern irgendwo

definieren. Also, das hier ist

dieses Feld

Tags ist halt ein

wie heißt

das in Django?

Weiß jetzt irgendwie

irgendwas, Foreign Key Field

irgendwas, aber man sagt halt, das ist halt

Many-to-Many-Relation irgendwas.

Weiß ich nicht, muss ich nachgucken. Aber auf jeden Fall definiert man

das halt wie eine Spalte in der

Tabelle. Also, Attribute

der Klasse sind halt Spalten in der Tabelle.

Und sagt man halt, das hier ist ein Many-to-Many-Beziehung

zu der Relation

Tags. Und dann hat man

die Link-Tabelle wird automatisch erzeugt. Man kriegt

das gar nicht mit.

Und im Code

hat man halt nur Bücher und Tags und halt

dann diese Beziehungen dazwischen. Und dann

ja, wenn man

sich das halt so hindefiniert hat

und dann halt alle Klassen, die man so braucht, beziehungsweise

alle Tabellen, die man halt irgendwie in der Datenbank haben möchte,

definiert hat mit den Spalten

und den Typen der Spalten und den

entsprechenden Constraints und den Indices und den ganzen

Kladderadatsch, die man auch sonst noch so braucht,

dann sagt man

Migrate

und dann werden die ganzen

Tabellen in der Datenbank

tatsächlich angelegt.

Oder

Make Migrations

ruft man halt zuerst auf und damit

werden halt so Migrationsskripte in Django

angelegt. Das sind auch einfach

nur Python-Files, in denen drinsteht, was

diese Migrationen tun sollen. Nämlich zum Beispiel irgendwie

Tabellen anlegen,

Indizes anlegen oder sonst irgendwas.

In die kann man auch beliebige andere Dinge

reinschreiben. Also man kann halt auch selber Migrationen

einfach so von Hand schreiben.

Wenn man zum Beispiel jetzt sowas wie, es gibt so

Datenbank-Trigger. Also man kann halt

sowas...

Ja, man könnte halt, also wenn

zum Beispiel

Nutzer taggen selber

und erfinden eine neue Kategorie.

Ja.

Ich überlege gerade,

mir fällt ehrlich gesagt jetzt gerade nicht so ein

tolles Beispiel ein, aber im Grunde, was das tut,

ist, wenn sich halt in einer

bestimmten Spalte irgendwas ändert,

dass dann automatisch andere Aktionen passieren.

Innerhalb der Datenbank.

Und das kann man halt

festlegen, haben auch einen SQL-Syntax

und man schreibt das halt einfach in eine Migration rein.

Ja, oder man kann auch sogar Sort-Procedures,

die halt dann irgendwie eine komplizierte Geschichte, die dann

irgendwie ausgeführt wird, wenn ein neuer Autor

angelegt wird oder sonst irgendwas.

Dann müssen vielleicht noch diverse andere Geschichten gemacht werden.

Das kann man

ganz normal in diese

Django-Migration auch reinschreiben. Man kann da die

SQL reinschreiben und

die werden dann mit ausgeführt und dann werden halt diese

Sort-Procedures oder Trigger in die Datenbank mit reingeschrieben.

Und sind dann halt da.

Und

was im Schema passiert

oder was da drin ist, das wird halt dann von

diesem Django-Migrationssystem verwaltet und

alle Migrationen, die ausgeführt worden sind,

werden halt auch wieder

in derselben Datenbank halt gehalten

von Django selbst. Da gibt es dann halt auch Tabellen zu.

Und man kann jetzt Sachen auch wieder zurückrollen. Also man kann

zum Beispiel sagen, wenn man eine Änderung gemacht hat

und feststellt, oh, die war nicht so toll, dann sagt man

halt einfach so migrate und dann gibt man die

Nummer der Migration an

davor und dann rollt sich die Datenbank in den

Zustand davor zurück.

Und dann

löscht man einfach die Migration und dann war's das.

Also das macht es halt sehr angenehm

damit zu arbeiten und sowas braucht man auf jeden Fall.

Also selbst wenn man jetzt sowas nicht wie Django verwendet,

sondern das alles von Hand macht, dann braucht

man auch irgendeine Art, wie man damit umgeht und das

war teilweise früher ziemlich übel. Also

keine so gute Unterstützung in den Frameworks für sowas

gab. Da hat man das halt irgendwie von Hand gemacht

und da passieren dann immer wieder Unfälle.

Man hat halt irgendeine

Datenbank vergessen oder

wenn man jetzt halt mehrere Datenbanken hat

oder

es geht irgendwie sowas verloren, man weiß nicht genau

in welchem Zustand die Datenbank ist, weil

irgendwie man meint, man hätte die ausgeführt, aber

dann ist es irgendwie doch nicht passiert

oder weil eben nirgendwo

drinsteht, in welchem Zustand die Datenbank ist,

sondern man nur Leute fragt

irgendwie so, also hast du die Migration jetzt eigentlich auf der

Produktionsdatenbank schon ausgeführt oder nicht?

Ja, ja, hab ich gemacht.

Das ist vielleicht auch nicht passiert.

Also es wäre schön, wenn das halt irgendwie selbst

auch in der Datenbank festgehalten wird,

in welchem Zustand man ist.

Ja, und das, jetzt so ein

Framework wie Django bietet einem dafür halt

kommen so wirklich relativ vollständige

Wir merken wieder, du bist ein Django-Fan.

Ja, ja, Art damit umzugehen.

Ja, kann man Flask, wenn man jetzt das andere

große Web

ja, Framework kann man jetzt

nicht da so wirklich zu sagen, aber die andere Paradigmen,

wie man Web-Anwendungen

in Python entwickelt,

wenn man das in Flask macht, hat man das

auch alles, ja, da gibt es dann SQL-Alchemy

als ORM

und halt, ich weiß jetzt nicht, das hat

einen Namen, die Migrationslösung

dafür, den entdecke ich mir jetzt gerade

nicht erinnern, und da geht das

alles auch. SQL-Alchemy ist sogar deutlich mächtiger

als der Django-ORM,

aber ist halt nicht integriert.

Und, ja, also

Flask ist auch super,

der Trade-Off ist halt so ein bisschen,

was einen Django so abnimmt,

ist halt, dass man

sich halt um viele Abhängigkeiten nicht kümmern muss,

weil man installiert halt Django und dann hat man halt einen Großteil

von dem, was man so braucht.

Und das wird halt dafür,

dass das alles konsistent bleibt und man upgraden kann

und so, dafür wird gesorgt, da muss man selber sich nicht drum kümmern.

Wenn man jetzt Flask macht und dann halt ganz viele

unterschiedliche Teile

hat und die ihre Versionen

ändern und so, dann muss man selber am Ball bleiben

und auch Konflikte halt selber auflösen.

Das heißt, man hat so langfristig mehr zu tun damit.

Aber dafür ist man halt auch

flexibler und kann halt, wenn einem

eine bestimmte Art von ORM besser gefällt, den halt

verwenden. Es gibt halt auch zum Beispiel irgendwie

neuere, also SQL-Alchemy ist sehr alt,

Django-ORM ist relativ alt.

Es gibt Peewee,

und Pony-ORM oder so

sind jetzt modernere Geschichten,

sieht besser aus, macht unten drunter

irgendwie was sehr ähnliches, aber

ja, genau.

Also ein Teil davon ist halt immer, wie man die

Relationen und Tabellen definieren kann.

Das sind meistens Klassen, die man dann halt aufschreibt.

Und dann erzeugt man daraus halt die Datenbankstruktur.

Und der andere Teil vom ORM

ist halt, wie man Abfragen auf die Datenbank halt

abfeuert. Und

das, was man eigentlich

fast bei allen ORMs dann so macht, ist

man

macht so Method-Chaining.

Ich weiß nicht, sagt dir das was?

Bis jetzt nicht.

Ja, gibt's auch so oft in

Data Science, also Pandas oder so, da macht man das auch.

Also man kann in Python,

ja, man kann ja irgendwas sagen, so man hat ein Objekt, Punkt,

Methodenaufruf,

oder Punkt Attribut, Punkt,

wieder noch was anderes, Punkt, wieder noch was anderes.

Wenn zum Beispiel eine Methode

ja ein Objekt zurückgibt, dann kann man auf diesem

Objekt wieder was anderes aufrufen.

Wenn ich das alles in eine Teile schreibe, wird das irgendwann relativ

lang. Aber wenn ich jetzt ein Statement

modellieren möchte, das halt viele Where-Bedingungen

hat, die Art, in Django

ORM das hinzuschreiben, wäre halt zu sagen, Filter

irgendeine Spalte

gleich

irgendeinen Wert oder sowas.

Aber dann hab ich noch ein zweites, dann sag ich Punkt, Filter,

nächste Spalte, wieder ein anderer Wert oder so.

Und das

wird halt relativ länglich. Daraus wird dann halt ein

Statement generiert, aber was ich

halt tun kann, ist zu sagen,

Klammer auf, und dann halt Query-Set, Punkt,

Filter,

Punkt, Annotate,

und dann Dinge

gruppieren oder so, oder neue Spalte

hinzufügen.

Und ich mach hinten noch eine weitere Klammer drumrum,

dann kann ich das halt auch einrücken. Und dann

rück ich das so ein, dass alle Punkte untereinander stehen.

Und dann hab ich halt so ein mehrzeiliges

Dings, was so ein bisschen

eine Zwischenform ist zwischen SQL und

Python-Code.

Ja, aber ich

spare mir dadurch sozusagen, dass

jedes Mal irgendeine Zwischenvariable zuweisen zu müssen.

Ansonsten könnte ich ja

natürlich sagen, Query-Set gleich, Query-Set, Punkt, Filter,

irgendwas. Und dann sag ich in der nächsten Zeile,

Query-Set gleich, Query-Set, Punkt,

Filter, noch irgendwie eine andere Spalte,

where, irgendwas.

Ich kann das aber auch alles in

ein einziges Dings reinschreiben.

Und man nennt das

Message-Chaining.

Ja, und das ist halt irgendwie

das, bei

Pandas ist es halt genauso, da hat man Data-Frames, auf denen man

Sachen macht, und die geben dann auch immer

wieder ein Data-Frame zurück, die Fehler der Methoden.

Und die kann man halt auch so chainen. Und dann hat man da oft

so mehrzeitige Dinge, wo halt die Punkte untereinander stehen.

Also wenn man nicht weiß, was das ist, das ist Message-Chaining.

Und das ist halt so eine Methode, um

Dinge halt in eine

State zu... Irgendwie schon mal ein bisschen gesehen, aber so wirklich

wissen, was das Message-Chaining heißt, ist natürlich...

Ja, genau. Und

im Grunde ist es halt dann, wenn man

OEMs, wenn man Queries in OEMs so macht,

ist es halt so ein bisschen, ist es so ein Zwischending

zwischen

SQL und Python, aber das funktioniert

dann halt so halbwegs gut, und das

ist dann halt sehr angenehm.

Und dann ist es nicht mehr ein Problem, wenn man jetzt

sozusagen diese Art von Logik an unterschiedlichen Stellen

im Code stehen hat, weil

die Statements, die rausfallen, sind halt alle gleich.

Und wenn ich jetzt irgendwie, keine Ahnung,

mir überlege, dass ich

eine bestimmte Art von Optimierung

machen möchte an den Statements,

dann wäre die halt

auch immer gleich.

Das heißt, dann habe ich halt dieses Problem,

dass ich sonst hätte, wenn ich das alles in einen

File schreiben würde, oder wenn ich

fast gleiche Statements in unterschiedliche

Files schreiben würde, wenn ich die

Statements beim Code haben will, das habe

ich damit dann nicht mehr. Und das ist natürlich ein sehr schöner Effekt.

Und das ist halt, ja,

das ist einer der Hauptnutzen von OEMs, also

ein anderer schöner Nutzen ist halt, dass man halt diese

ganze Migrationsgeschichte, wie ändern sich Sachen, halt auch

automatisiert hat, beziehungsweise die ganzen Prozesse drumherum

irgendwie zumindest mal abgebildet hat.

Ja, also sind wir jetzt klein und niedlich,

und das haben wir jetzt gemacht.

Genau, und dann würde man so ein Framework verwenden, OEM,

und dann ist man eigentlich,

ja, das geht alles ins Git,

gibt Versionskontrolle dafür, und dann

das ist eigentlich alles schon relativ komfortabel.

Ähm,

ja.

Ähm,

Ja, was passiert jetzt? Also wir sind klein,

und jetzt haben wir das schon gebaut, aber

ja, wann funktioniert das denn nicht mehr so?

Äh, ja.

Ähm,

genau.

Wir haben als Onlinehandel einen

riesen Vorteil gegenüber

stationärem Buchhandel, weil

das ist auch eine interessante Statistik.

Das kommt, glaube ich, aus diesem,

ähm, Buch-Longtail, irgendwie,

äh, von, wie soll ich sagen, von

Wired-Redaktion, ah, weiß ich, hab den Namen vergessen.

Äh, jedenfalls, ähm,

schreibt er da, dass Amazon

macht die Hälfte des Umsatzes mit

Büchern, die nicht in den Top 300.000 sind.

Mhm.

So, äh, weil eben

Bücher verkaufen, äh,

so ein, so ein,

oder verkaufte Bücher hat so eine Longtail-Verteilung.

Also es gibt halt

äh, sehr, Leute wollen sehr

unterschiedliche Bücher kaufen. Also es

werden viele Bücher verkauft, aber von denen nur ganz

wenige. Und das ist

halt blöd für einen

Laden, der die Bücher halt physisch vorhalten

muss. Weil auch selbst wenn Bücher nicht so groß sind,

ich kann halt in so einem Innenstadt-

Buchladen kann ich halt

irgendwie ein paar tausend Bücher haben.

Äh, und dann ist halt irgendwie Schluss.

Und dann muss ich mir überlegen, welche das sind. Aber wenn jetzt,

also, nehmen wir an, ich hab...

Das hat aber auch ein Zielpublikum. Das heißt, ich weiß genau, hey,

in mir kommen jetzt nur ganz wieder alte, antiquarische,

ähm, interessierte Menschen rein.

Dann sollte ich vielleicht dafür sorgen, dass in meinem

Laden viele antiquarische Bücher sind.

Oder es kommen jetzt noch ganz viele hippe Leute rein,

die wollen alle, was sie bei IT wissen, sollte ich vielleicht in ein IT-Buchladen.

Ja, ja. Aber selbst, selbst wenn du

jetzt, äh, all diese Zielgruppen zusammennimmst

und dann irgendwie das riesige, den riesigsten,

äh, also, das ist halt das Problem. Wenn die

Zielgruppe zu klein ist, dann lohnt sich das

nicht. Äh, aber wenn sie, äh, selbst

wenn du jetzt einen riesigen Buchladen hast, in dem 300.000

Bücher passen, was äh, ziemlich groß sein müsste,

dann machst du

immer nur, äh, trotzdem noch die Hälfte des

Umsatzes von Amazon, weil

Amazon macht halt nochmal so viel Umsatz mit den

ganzen Rest. Das heißt, sie haben dann, sie können

einfach viel besser skalieren,

weil sie einfach viel mehr Bücher verkaufen.

Und, ähm, ja, dagegen,

ich wüsste nicht, dass es da irgendein Mittel gegeben gibt.

Ich fürchte... Was aber auch bedeuten würde, dass Amazon

auch diese Minus-Eins-Bestellung annehmen müsste, weil das

müssen sie auch irgendwo in einem riesigen Lager jedes

Buch liegen haben. Ja, müssen sie tatsächlich wahrscheinlich.

Oder sie müssen es halt on demand irgendwie drucken können

oder so. Gut, klar, sie müssen

damit irgendwie umgehen. Äh, auch der

stationäre Buchhandel geht ja irgendwie dann damit um,

so damit um, dass man dann halt Sachen da bestellt.

Zum Beispiel, äh... Hey, Autor, schreib doch

bitte nochmal eine neue Vorstellung.

So ein paar Bestellungen, ja.

Aber, äh,

ja, ich meine, du hast halt als, äh,

als stationärer Buchhandlung

hast du ja keinen Vorteil mehr, wenn

du dann auch wieder bestellst, weil dann

machst du halt zwei Sachen und die eine, ja,

und dann als Amazon hast du einfach

einen strukturellen Vorteil,

fürchte ich. Äh, und dann kannst du...

Okay, und dann ist es cool, weil dann können wir einfach mit unserer

Postgres-Lösung direkt so unter dem ORM...

Genau. Die interessante...

Also mit 3.000 Millionen, also mit 3.000 Millionen ist das überhaupt kein Problem,

äh, also da könnten wir auch, also ich würde sagen,

so ein Markt wie Deutschland kannst du wahrscheinlich tatsächlich mit

einer Datenbank und mit allen Büchern, die es überhaupt gibt,

locker bedienen. Das ist

kein so großes Problem.

Äh, wenn es jetzt

nur darum geht, die Bücher zu verkaufen.

Aber, äh, wenn wir

jetzt, äh, zum Beispiel eben sowas rauskriegen

wollen, wie, äh,

was sind eigentlich die Top 300.000 Bücher?

Wo kommt denn diese Zahl eigentlich her?

Ja, und, äh,

überhaupt rauszukriegen, okay, wir machen die Hälfte

unseres Umsatzes mit den nicht, mit Büchern, die nicht

in den Top 300.000 sind,

dann, äh, müssen wir, äh, nicht nur

die Bücher speichern, sondern dann müssen wir halt

auch, äh, speichern

zum Beispiel, welche Bücher gekauft worden sind und so

und die, also die Historie aller Bestellungen und so.

Und das ist dann halt unter Umständen

viel, viel mehr.

Und, äh, dann, äh,

wird es allmählich problematisch, weil dann haben wir

unterschiedliche, äh, Use Cases,

äh, oder unterschiedliche Abfragemuster.

Also wir haben zum Beispiel diese

Transaktions, ähm,

äh... Also das Lager, das einfach immer noch

weiß, wie viele Bücher sind da und das schicken wir raus.

Oder wir haben jemanden, der macht Marketing oder sowas.

Das System, das macht halt Bestellungen, oder wir haben halt Anfragen, die

Bestellungen machen oder solche Sachen wie

zeig mir alle Bücher in, äh, Seefacher-Romane

oder so. Äh,

aber die, diese Art von

Anfragen wie, sag mir mal, wie viel Umsatz

ich mit den, äh,

äh, äh, nicht in Top 300.000

enthaltenen Bücher im letzten Jahr gemacht habe.

Das ist eine ganz andere Art

von Anfrage.

Ja, während die, die Anfragen vorher, die machen

immer nur auf kleinen Datenmengen in der Datenbank,

irgendwas, immer zeilenweise meistens.

Und, ähm,

oft ändern sie auch irgendwas oder schreiben

irgendwas. Aber gut, Großteil, wenn man noch die

große Mehrheit wird Read-Anfragen

sein, aber die, äh, beziehen

sich normalerweise nicht auf wahnsinnig viele

Daten, äh, Teilen, sondern immer nur relativ

wenige oder wenige tausend Zeilen.

Und, ähm, ja, eben operieren halt

auch ja zeilenweise während diese andere

Anfrage jetzt dieses, wie viel Umsatz.

Ja, das ist halt dann

nur noch eine Spalte aus den Bestellungen

und dann auch, äh, geht es

wahrscheinlich aber über lange Zeiträume,

über ein Jahr, mehrere Jahre

und dann halt über alle Bücher.

Das ist eine Anfrage,

die geht halt über ganz, ganz, ganz, ganz,

ganz viele Zeilen.

So, und jetzt beißen sich die, diese, diese

Abfrage-Muster beißen sich halt massiv.

Mhm, mhm. Äh, wer, also,

weil, äh, das Problem ist, dass die

Datenbank irgendwie gewährleisten muss, dass die,

deine Sicht auf die Welt, also auf die Datenbank,

konsistent bleibt, während die Anfrage läuft.

Die Anfrage läuft jetzt aber wahrscheinlich relativ lang.

Du musst hier irgendwie alle Daten, die in der Datenbank

liegen, oder einen Großteil davon, musst du dir sicher angucken,

wenn sie dir hinterher so was sagen,

eine Zahl geben will, wie viel Umsatz waren das jetzt so.

Ähm,

und währenddessen werden aber

Bestellungen abgearbeitet oder werden Dinge gemacht,

Sachen an der Datenbank geändert,

die jetzt aber nicht direkt

durchschlagen können auf deine Anfrage, sondern

da werden immer nur Kopien gemacht, oder es,

ja, und sozusagen, es wird dann halt ein Timestamp

mit reingeschrieben, es wird halt, nein, das ist Multiversion

Concurrency Control. Äh,

Multiversen! Ja,

Multiversion Concurrency Control,

das heißt, die Datenbank

ist halt in einem unterschiedlichen Zustand,

je nachdem, wer sie, wer gerade fragt.

Und für die Transaktionen, die eine Bestellung ausführen, ist sie jetzt

in einem anderen Zustand als für dieses langlaufende

Query. Und das Problem ist halt, je länger

diese Query läuft, umso länger muss die Datenbank

jetzt mehrere Versionen ihrer selbst aufrechterhalten.

Was dazu führt, dass du halt auch

mehr Speicher brauchst und was halt eine komplizierte

Geschichte ist. Und das ist halt, ja,

wenn das Problem ist, wahrscheinlich wird man dann halt

irgendwann sehen, man wird so mit einfachen Analysegeschichten

anfragen und irgendwann wird man halt merken, so morgens um neun

wenn dann halt irgendwie die, die, äh,

äh, Business Intelligence

Abteilung irgendwie anfängt, äh, wenn

da die Analysten sitzen und dann irgendwie, ja gut,

ich weiß nicht, am Anfang wird man sowas noch nicht haben, aber

irgendwann wird man das gleich dann, wenn die halt ihre

Analysequeries abschießen, dann

wird plötzlich die Webseite langsam.

Ja, weil halt die Datenbank langsam wird,

weil die Queries werden langsam, weil, äh, plötzlich

äh, muss die, äh, muss die Datenbank

irgendwie mit mehreren, äh,

Zuständen irgendwie rum

jonglieren. Ja.

Das ist blöd. Und dann muss man sich halt, äh,

sowas überlegen. Und, äh,

das ist dann halt so der Moment, äh,

wo man dann sagen muss, okay, wir, wir

können das nicht mehr. Es wäre schön, alles in einer Datenbank

zu haben, aber es geht nicht. Diese beiden Use Cases

sind so unterschiedlich, dass man das leider

nur dadurch ordentlich abgebildet kriegt,

dass man das halt in unterschiedliche Systeme packt.

Und, ähm,

ja, also das eine nennt man,

äh, auch, äh, irgendwie OTP,

ja, Online Transaction Processing.

Das ist halt sozusagen der

Webseite, also Datenbank ist hinter

einer Webseite, die irgendwie Bücher verkauft und, und Prozess

hier Transaktionen, Bestellungen.

Und der andere Teil nennt sich, äh,

OLAP, äh, Online Analytical, äh,

Analytical Processing.

Und, äh, ist halt das so, wenn

man das mal gehört hat, irgendwie, wenn Leute über Data Warehousing

sprechen oder Data Warehouses oder so, das ist halt

das. Ähm,

und, äh,

genau, äh, das sind beides

meistens relationale Datenbanken,

wenn man anfängt jedenfalls.

Äh, aber die sehen

unterschiedlich aus. Äh, also wir haben

unterschiedliche Anfragen werden gestellt.

Ja, Analyseanfragen sind oft, laufen

länger, gucken sich viele,

viele Zeilen an.

Äh, Transaktionsanfragen sind oft

kurz und, ähm, ja, gucken

sich wenige Zeilen an. Und da geht's auch darum,

dass die Latenz relativ kurz ist. Bei vielen Analyseanfragen

ist das gar nicht so wichtig. Äh,

dass die jetzt, ob die jetzt eine Minute oder länger

oder weniger lang laufen, ist gar nicht so, gar nicht so

entscheidend. Und auch die Analyse-Datenbanken

sind oft viel, viel größer, weil man halt historische

Daten mit drin hat. Äh, was

halt für eine Transaktionsdatenbank tödlich wäre, weil

die, bei der es möglichst das

komplette, äh,

Working-Set der Datenbank im Hauptspeicher,

damit das halt alles schnell geht, damit die Latenz

äh, niedrig bleibt,

damit halt die Webseite schön, äh,

sich schön snappy irgendwie anfühlt.

Äh, und

bei, äh, bei den, den Analyse-Datenbanken

ist dabei unter Umständen wichtig, dass ich

halt historische Daten da halt auch mit drin haben kann.

Und die sind, werden dann halt vielleicht so groß,

dass man das halt nicht mehr im Hauptspeicher halten kann.

Ja, aber, äh,

die Queries werden dann halt langsam,

aber das ist halt möglicherweise,

wichtiger, historische Daten zu haben, als dass

Queries halt schnell sind. Und dann, äh,

wenn, wenn sich eine, eine Query

irgendwie ein paar Millionen oder paar Zehn Millionen Zeilen anguckt,

dann ist es eh nicht mehr schnell, selbst wenn es im Hauptspeicher ist.

Und ob es dann jetzt eine Minute oder zwei Minuten dauert,

das hat dann auch irgendwie wurscht.

Ja, äh, genau. Und dann, äh,

hat man eben diese beiden unterschiedlichen Systeme

und dann kriegt man halt aber auch genau diese Probleme,

die man dann hat, wenn man mehrere,

mehrere Sichten auf die Welt,

äh, hat oder einen Status, äh,

irgendwie eines, man hat jetzt keinen gemeinsamen Status

mehr, sondern man hat jetzt, äh,

äh, den Status

des Systems in

unterschiedlicher Form in unterschiedlichen Datenmanken.

Äh, das heißt,

man muss jetzt zum Beispiel die Transaktionen, die irgendwie

in dem einen System aufgelaufen sind, überführen

in das Analyse-System.

Äh, das macht man

üblicherweise bei einem Prozess, der nennt sich, äh,

ETL, äh, Extract, Transform,

Load. Und man halt die, äh,

Daten, die einen interessieren, halt täglich oder so.

Also meistens fängt man so, so was an wie,

ja, das sind halt dann Jobs, die nachts laufen,

äh, wenn halt die Datenmangel sowieso nicht so

unterlasst sind, weil nicht so viele Leute, äh,

äh, einkaufen, äh,

liest man halt irgendwie alles, was einen so