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 den 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.

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.

Wollen wir das eigentlich 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?

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.

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 Modules 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 drum herum

kommen, irgendwann etwas mit Datenbanken zu machen.

und

ja, dafür muss man sich halt dann auch

nicht nur mit Python auskennen, sondern man 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.

Wir werden noch ein bisschen darauf eingehen, was ist das überhaupt,

eine Datenbank, unterschiedete einzelne 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.

Da hat man uns gedacht, nehmen wir einfach 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 jeder 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 darin kann man das vielleicht ganz gut erklären.

Ja, dann 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 gedanklich dazu macht. Wie sieht denn meine Struktur der Daten überhaupt aus? Was will ich denn damit machen? Wie würdest du da direkt vorgehen?

Ja, also das kommt tatsächlich auf den Anwendungsfall an und was sich halt in der Praxis in den letzten Jahrzehnten so durchgesetzt hat, sind relationale Datenbanken, aber es gibt halt auch diverse andere Arten von Datenbanken und die haben alle so ihre Berechtigungen.

Für alle, die das noch nicht drauf haben, ist es so SQL oder NoSQL, genannt oft.

Ja, es hängt halt davon ab. Also man kann natürlich auch einfach Python-Objekte nehmen, die irgendwie serialisieren, nennt man das. Also zum Beispiel gibt es in der Standardbibliothek 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 Datenmarken eine sehr wichtige Geschichte. Und man könnte jetzt zum Beispiel diese Byte-Folgen oder Strings nehmen und die halt teilenweise 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 Zeilen, schreibt das Ganze in ein File.

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 Spieler-Daten aus dem Sport, habe ich einfach alle Informationen über einen Spieler in eine Teile gepackt und die teilenweise 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-Zeilen 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. Ist 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 Webentwicklung auch häufig gemacht, das nannte sich dann Flat Files, Datenbank mit Flat Files, man nimmt einfach Files und schreibt den State da irgendwie rein und natürlich ist auch das Filesystem 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, Slash bei Unix-Systemen oder was weiß ich, 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 Verzeichnisse, die es da gibt, auch schon

so Metadaten definiert, dass man halt weiß,

so bestimmte Sachen sind halt in einem bestimmten Verzeichnis und so.

Und

das Ganze gibt es halt auch über

Netzwerkgeschichten.

Die bekannteste hierarchische Datenbank

im Netz ist halt sowas 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 Datenbanken

betreiben kann.

Aber vielleicht, was ich

ganz gerne auch nochmal

ansetzen 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, was 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

Datenbanklösung

der Welt,

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.

Und

das ist, genau, das ist halt

eigentlich, ach so, und vielleicht sollte man sich

erstmal grundsätzlich überlegen,

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.

Dafür hat man umgangssprachliche

Definitionen,

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 hat, minus 3,5, was denn?

Ja, genau, richtig.

Grad Fahrenheit.

Und 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 Temperaturspalte.

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 Datenmarken 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.

Und das halt 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 als so und so oder irgendwie sowas.

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

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.

Das werden wir heute, glaube ich, nicht machen.

Doch, doch, doch.

Ja, doch, doch, doch, alles.

Ihr müsst heute lange, lange Geduld mitbringen

oder eine große Runde durch den Park

oder 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 hätte

so ungern davon ab, so ins Detail zu gehen, weil ich finde das

unheimlich interessant, was da alles noch so drinter steckt.

Ich bin da 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 mit dem Beispiel an oder wolltest du noch so ein paar

grundsätzliche Dinge über Daten? Genau, ich würde einmal

grundsätzlich darüber, was gibt es für unterschiedliche Arten von Datenbanken,

auch um halt dann,

ja, um

darauf dann wieder Bezug nehmen zu können in dem Beispiel

und vielleicht auch das, was halt

jetzt durchgesetzt hat, jedenfalls

das ist halt, eben

hierarchische Datenbanken gibt es schon

ganz lange und

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 irgendwelche Dinge damit später

machen, wie man das so grundsätzlich

eingehen 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 in

eigenem 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.

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 nichts zu suchen haben, oder?

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

Oh, jetzt kommen wir direkt mit den Normalisierungen.

Weil es nicht wirklich Beziehungen zwischen Tabellen gibt und das in Datenbanken gibt es halt alles schon und da gibt es, wenn 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, relativ großes Problem, denke ich, dass 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 irgendwie vor zehn Jahren ungefähr irgendwie so einen 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 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 der 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 der 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 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

Domain, aber... 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 hat halt,

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, naja, 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 da machen möchte, 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 also aus meiner

Perspektive auch so die beiden

Dinge, wo man...

Wenn man in Firmen

so leichte Gewinne,

die man machen könnte, also die

beiden Themen, die halt vollkommen

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.

Bei denen ist halt Verständnis, was jetzt

Git ist und wie man das verwendet, irgendwie

durchaus angekommen.

Mal bitte den Git-Flow.

Aber

in den meisten anderen Abteilungen,

wo es nicht um Programmieren geht,

die haben von solchen Dingen noch nie

irgendwas gehört. Dann nimmt man Tippex und

malt da kurz die Buchstaben, die falsch sind, raus

und fahrt dann da drüber. Und wenn man

wissen will, was da vorher stand, dann muss man das Tipp-Eck abkratzen.

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 geht.

Tabelle 1, Tabelle 1 neu, Tabelle 1

neu, neu, neu, final und

ja, jetzt erst wirklich und

allerneueste Version. Also da

könnte man mit wenig Aufwand viel erreichen

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

Habt ihr jetzt 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, viele Leute da so

Excel mit irgendwelchen Makros drin oder

irgendwelche Skript-Schnipseln drin haben,

warum die das verwenden.

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.

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 Programmierer-Sicht

nicht so das, was man tun sollte.

Man kann damit Stunden um Stunden um Stunden um Stunden

Genau, aus Programmierer-Sicht 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 bald mit 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, irgendwie 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

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

einen Vorteil dadurch, 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 so richtig

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

genau, also eigentlich wäre das, was

viele Leute damit machen, die werden

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

mehrere Leute drauf zugreifen und Dinge ändern,

dann sorgt die Datenbank dafür,

oder das Datenbankmanagementsystem,

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 sie

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 sie andere Paradigmen

durchgesetzt hätten, haben sie

aber irgendwie nicht.

Und jetzt sind halt so

relationelle 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,

um mal zu sagen, was es sonst noch alles gibt.

Es gibt halt

Dokumentendatenbanken, ja, gibt es auch schon

ganz lange. Lotus Notes

ist ja so ein Beispiel für

ist ja früher Microsoft

auch ganz populär.

CouchDB,

MongoDB, die

fallen auch in diesen

Dokument-Datenbank-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

Lotus Notes-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 dahin schickt.

Darunter fallen so Sachen wie Redis

oder Memcached oder so

oft zum Cachen verwendet, aber manchmal können sie auch

kompliziertere Sachen oder weiter

strukturierte Daten. BerkeleyDB war

lange ganz groß, wird 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,

HBase.

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, sondern

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,

vielleicht kann man das nachher nochmal

im praktischen Beispiel ein bisschen besser erläutern.

Ja, genau, aber das ist halt

so eine ganz andere Art von

Datenbanken, die aber auch, also da würde

ich sagen, das hätte auch sich anstelle von relationalen

Datenbanken durchsetzen können.

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 ein Grafendaten-Button.

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-DV oder.

TimescaleDB

oder halt sowieso

für, du hast halt ein bestimmtes Problem

wie, du möchtest dieses

bei Google sieht man, 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, und manchmal

sind solche Funktionen auch in

so verbreiterten

Datenbanken enthalten, aber es gibt halt

auch mal spezialisierte Geschichten dafür.

Ja.

Vielleicht die ganzen Basissachen werden noch komplett

nicht kurz erwähnt.

Keine Ahnung, MySQL

oder Postgres. Achso, 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

Geschichten.

DB2 von IBM.

Oder zur Historie,

im Grunde die,

nachdem dieses Paper

irgendwie, das sollte man

in die Schonungs packen, das ist sehr empfehlenswert, das nicht mal

zu lesen von Headquart. 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 die B2 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.

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 und set of the art

immer noch dabei, es kommen 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, Advanteste,

Die fortschrittlichste Open-Source-Datenbank,

ja. 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 als

Backend für Webseiten

verwendet man normalerweise nicht. Oracle ist halt auch

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.

Ich meine, einer der

ich weiß nicht, ob es

der Gründer selber war, der war auch

Produktmanager bei Microsoft, glaube ich, insofern

die machen viel auf dem Microsoft-Stack

und holen da unglaubliche Sachen raus.

Also die haben irgendwie ein halbes Rack oder

das ist jetzt auch schon lange her, dass ich

da irgendwie Artikel zu gelesen habe, aber

das letzte Mal, dass ich das gesehen habe, war

Stack Overflow tatsächlich unter den Top Ten

der trafficstä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. Und das ist überhaupt so was,

was halt wahrscheinlich viele Leute nicht wissen,

die jetzt 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 Hauptsprecher.

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, ist halt

der größte Datenbankbereich eigentlich.

Ja, vielleicht

können wir dann, wollen wir zu dem praktischen

Beispiel. Ja, 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 jetzt uns jetzt so, ah, da liegen jetzt ganz viele Bücher auf dem Boden und dann will irgendjemand bestellen, dann muss dann irgendjemand in die Garate 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 lange 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, 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 Autor, 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.

Wir könnten Suche und Ersetze machen und dann machen wir sowas, dann machen wir für jedes Jahr, das wir 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 das 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 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, anderes Beispiel wäre User,

die jetzt auf der Webseite irgendwas einkaufen wollen oder so.

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, es 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

vergisst 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 Dinge, die man einmal gefixt hat, dann nochmal auftauchen.

Das ist doch bestimmt schon einmal passiert, oder?

Also mir hat das früher ständig passiert und dann ist mir irgendwann aufgefallen,

oh, ich mache eine Funktion und dann mache ich die Funktion auch.

Dann macht man eine 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 ist bei Datenbanken halt auch nicht,

weil das beißt sich so ein bisschen mit anderen Anforderungen, die man hat.

Wenn es halt schnell sein soll, dann ist das manchmal etwas schwierig, weil relativ nahe Datenbanken, dann wenn man halt viele Tabellen miteinander verknüpft, man nennt das halt Join, das heißt man kann halt anhand von diesen Verzweigungs-, also Fremdschlüssel-Dingsies kann man halt Tabellen aneinander verketten.

Man kann sich das vorstellen, man legt die halt sozusagen nebeneinander, sodass halt die Spalte mit dem Schlüssel übereinander liegt und wenn man das mit vielen macht, dann werden die Abfragen langsam.

So ein bisschen wie an so einem Spielautomaten.

Wenn ihr so einen einarmigen Banditen habt,

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

und wenn ihr dann parallel sind und alles zeigt, gewinnen,

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

Dann hat man die Zeile

von dem Schlüssel irgendwie zusammengeführt.

Ja, genau.

Ja.

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.

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 der Unterschied zwischen den Normalformen sind.

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 jetzt tatsächlich erstmal hin

und nimm ein Whiteboard, einen Zettel

und schreib mir auf, wie die Daten aussehen

sollen. Ja, ja, tatsächlich. Also wenn ich

irgendwie eine 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?

Ja,

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

Das ist 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 das alte Datenbanken noch kompatibel sind oder sowas, oder?

Ja, dass man das so ändert,

dass nicht irgendwelche Inkonsistenzen entstehen.

Und auch, dass halt...

Wie wäre das jetzt bei unserem Beispielbeispiel?

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.

Aber vom Cover, jemand, oder das

Genre oder sowas, jemand sammelt Seefahrerbücher.

Ja, 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,

Militristik,

Komba, Seefahrer Roman oder

Komba, schreibt man jetzt Komba 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 machen sollte, ist halt, dass es

diverse Anfragen halt schwierig macht

und dass man es auch sehr schlecht ändern kann

und dass wenn man was ändern kann, man Sachen kaputt machen,

weil

Inkonsistenzen entstehen können und so.

Dann zieht man erst mal

diese Dinger auseinander und sagt halt,

okay, nicht in einer Spalte

mehrere Tags reinschreiben,

sondern dann hätte man sozusagen

eine End-to-End-Relation, also nicht nur,

wo ein Fremdschlüssel in der einen Tabelle zu einem Fremdschlüssel

in eine andere Tabelle passt, sondern man hat

dazwischen eine Link-Tabelle. Man hat jetzt einmal Tags

als Relation und einmal halt die Bücher

als Relation oder als Tabellen halt

und dazwischen hat man jetzt noch eine Link-Tabelle

zwischen oder Link-Relation zwischen

Büchern und Tags, 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 der, 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 1.000 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,

ein paar 10 Millionen Zeilen oder so lang ist,

wo halt jedem Buch ein paar Texte zugewiesen werden.

Und dann ist alles wieder schön in der 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 Texts oder Kategorien sind,

dann würde man versuchen,

wahrscheinlich Nested Sets nehmen.

Das ist, kann man sich mal angucken,

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 an jede,

man hat so eine Kategorie einen Baum und man schreibt dann an

jedes Element

in dieser hierarchischen Struktur,

den traversiert 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

rausselecten kann und so. Aber das ist dann

halt schon so wirklich für Fortgeschrittene.

Und im Endeffekt,

wenn man jetzt große

Grafenstrukturen hat oder Bäume,

dann wäre es wahrscheinlich besser, das gar nicht mehr in einer 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 so eine Relation an Datenbanken machen kann.

Ja, also das Dorsch nach der Garage ist mittlerweile rausgewachsen,

also 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,

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 Datenbanken,

sind halt so Transaktionen-Prozessen,

So 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 einen 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...

Mir fällt direkt wieder eines der Probleme ein.

Okay.

Ja, 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 die 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 Prozent dieser Kunden einfach gar nicht am Ende kaufen,

sondern irgendwie wieder abspringen, weil die dann sagen,

na ja, doch nicht oder so.

Und dann hätten jetzt ja alle sich bei sich einen Warenkorb reingedickt

und wenn nur noch eins da ist,

vielleicht hätte der zweite direkt angezeigt bekommen,

geht 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.

Du kopfst in die Luft.

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

Genau, du kannst, sobald du draufdrückst,

in dem Moment, wo sozusagen diese Bestelltransaktion gestartet wird

und dann in der Datenbank aber

die Bedingung, 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 dem User eine Fehlermeldung 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, ätsch, ätsch, du kriegst doch kein Buch, weil war keins mehr da. Das ist 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 nicht mehr, also 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 da im Grunde kein Problem, kann man das sauber lösen.

Ich hatte ja so etwas, 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, deine Überweisung wurde vernünftig ausgeführt. Und dann zwei Wochen später kriegte ich dann so eine Mahnung und dann habe ich nochmal aufs Konto geguckt und die Transaktion war weg. War nicht da.

Was habe ich dann da angerufen? Da haben die 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 größeren Menschen.

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-Processing gibt, nachts. Also die Sparkassen haben das lange gemacht.

Man schmeißt dann manuell die ausgedruckten Briefchen ins Überweisungs...

Lochkarten.

Fällt 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, 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, wo 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 mal 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. 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 genau so ein Fall wie, ich kaufe ein Buch, ist halt ein Ding, in der Daten 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 keine 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 ein System habe, das das nicht macht und ich erzeuge die Bestellung, habe jetzt in meiner Bestellungstabelle das Ding erzeugt, sage jetzt in der Lagerstandstabelle dieses Buch 1 weniger und dann sagt das, hier habe ich ein Constraint auf, es darf nicht weniger als 0 werden, also minus 1 Bücher ist schwer, das funktioniert irgendwie nicht so richtig 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 und die Mann 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 dann sagen,

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

aber das... Oder das Buch wird gedruckt oder sowas.

Ja genau, einfach normal produziert. Aber dann verändert sich möglicherweise das Ziel dafür, wann es halt ausgeliefert wird oder so. 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 drin steht, 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 Schemaende, aber am besten mache ich das Schema am Anfang schon so fertig, vollständig, dass das unproblematischer geht.

Das ist ein bisschen ein Problem. Man sollte ein Schema schon von Anfang an halbwegs so designen, dass es halt passt. Es ist später nicht mehr so ganz einfach, das zu ändern. Man kann das natürlich ändern, aber es ist auf jeden Fall…

Aber das fängt ja ein bisschen vom Geschäftsmodell ab. Wenn ich jetzt auf einmal merke, oh, ich verkaufe jetzt vielleicht gar keine Bücher mehr, sondern, weiß nicht, kompliziertere Produkte oder sowas, 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 wird das ja notwendig. Also ich kann ja nicht jedes Mal eine neue Darkman anfangen, sondern ich muss ja auch gucken, dass sie irgendwie mit skaliert.

Ja, 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 das halt nicht so einfach ist.

Möglicherweise finde ich es immer iTunes

oder 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 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

zehn Jahre später,

bis heute haben

halt irgendwie Apps einen Titel und eine Länge,

Songlänge oder sowas, ja, 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. Okay. Also wenn ich jetzt

also die Daten selber zu ändern, ist glaube ich

nicht so das Problem. Aber 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 wo

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's 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 deine App eine Songlänge

hat, ja.

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 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 Cover 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

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 in den nächsten 20 Jahren nicht mehr so wahnsinnig

viel dran. Und dann 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.

Die können sich

dummerweise unter Umständen, je nachdem

wie... Daten über Daten

über Daten. Ja, das kann sich dann,

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, weil 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 lässt, ist halt auch nicht Schema lässt, 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 und dann passieren furchtbare Dinge

und also 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

es ist immer so schön, irgendwie

Daten altern wie Wein,

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, 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

Sachen und

Applikationscode erörtert

wie Fisch.

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

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

altern auch die Daten

nicht gut und deswegen ist es eigentlich schon sinnvoll

eine Trennlinie zu haben und 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 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 Lagersachen geben

mit einem Lagerstand von

Minus irgendwas. Das darf halt nicht sein.

Da ist ein Fehler passiert, dann 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 so was

wie ein Gehalt, das darf auch nicht negativ werden.

Oder dass halt

bestimmte Datumsinformationen

halt nicht so und so sein können.

Ja.

Oder dass man halt tatsächlich auch was mit Postgres machen kann. Postgres ist halt wirklich eine schöne Wahl, wenn man jetzt mit so einer Geschichte anfängt. Das kann so tolle Sachen wie, 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 Webseite 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 also 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

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

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

einen Pointer in der Bestellungstabelle, der

halt auf 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 einen Index so definieren, dass er nur

Sachen, Bücher

mit reinnimmt, die halt

auch tatsächlich noch verkauft werden.

Und das heißt, es ist nicht so,

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

sehr viele Features, zum Beispiel

jetzt im Unterschied zu MySQL, wo das halt,

wo 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, 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

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, Ball-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 jetzt. Ja, doch, doch.

Ja, jetzt dann. Ja, ja.

Wie viele Bücher passen in der Garage? Wenn du deine Lagerhaltung,

und das möchtest du halt im gleichen System machen, damit

eben du nicht das Problem kriegst, dass

du den Start-Estate 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

über die du Bücher verkaufst,

wenn das unterschiedliche Systeme sind,

dann musst du den State-Zwischendienstensystem

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

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 gibt dann sonst direkt einen Fehler aus der Datenbank.

Hey, nur dürfen wir nicht, geht nicht.

Und wir haben das Schema dabei erarbeitet für unseren kleinen Laden

und so sollten wir dann los.

Und dann kann deine 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, nur mache 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.

Du hast minus zwei Bücher und dann

sagt die eine Datenbank, du darfst aber eigentlich nicht.

Dann sagt die eine Datenbank, ja, hab ich aber.

Da kommst du halt in Teufels Küche.

Man könnte sich vorstellen, dass das eine gute Idee wäre.

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

das ist keine gute Idee. Das ist doof.

Das ist auch vielleicht ein bisschen unintuitiv.

Und natürlich,

nachher muss man Sachen funktionierender

rausnehmen und man muss dann das

in mehrere Systeme aufkleiden. 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?

Wir sind klein und niedlich. Wir haben

Postgres, machen alles

über Postgres. Wir haben 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 das?

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 ja, das ist halt immer ein bisschen Fremdkörper.

Wenn man jetzt einen Python-Code schreibt,

dann hat man jetzt so ein SQL-Statement.

Das passt von der Syntaxe ja überhaupt nicht in Python rein.

Da muss man einen langen String machen, der irgendwie vernünftig aussieht.

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

Genau, 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 einen Vor- und Nachteil. Das hat den Vorteil, dass man halt

Sachen leicht ändern kann, aber es 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, wo man dann halt gar nicht wirklich mitkriegt, dass das SQL unten drunter ist, sondern man schreibt halt ganz normalen 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 mappt, 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, nee, irgendwas

foreign-key-field irgendwas, aber man sagt halt,

das ist halt many-to-many-relation

irgendwas, weiß 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 dann 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 Inzides und den ganzen Kladderadatschen,

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 ...

Was ist das?

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.

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 jetzt 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,

braucht man auch irgendeine Art, wie man damit umgeht

und das war teilweise früher ziemlich übel,

als es keine so gute Unterstützung

in den Frameworks für sowas gab, 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, ja, 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 noch nicht passiert.

Also es ist sehr 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 das andere Paradigma,

wie man Web-Anwendungen

in Python entwickelt,

wenn man das mit Flask macht, hat man das

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

als ORM

und halt, ich weiß jetzt nicht, das hat

irgendeinen Namen, die Migrationslösung

dafür, an den ich mich jetzt

gerade nicht erinnere. Und da geht

das alles auch. SQL Alchemy ist sogar deutlich

mächtiger als der Django OAM,

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 und 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 PV

und PonyORM oder so, das 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

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

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

wieder was anderes aufrufen.

Wenn ich das alles in eine Zeile 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-Organs

das hinzuschreiben, wäre halt zu sagen, Filter

irgendeine Spalte

gleich

irgendeinen Wert oder sowas.

Aber dann habe ich noch ein zweites, dann sage ich Punkt, Filter, nächste Spalte

wieder irgendeinen anderen 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 QuerySet.Filter

Punkt

Annotate

und dann Dinge gruppieren

oder so oder neue Spalte hinzufügen

und ich mache

noch eine weitere Klammer drumrum, dann kann ich das halt auch

einrücken und dann rücke ich das so ein, dass

alle Punkte untereinander stehen und dann habe ich halt so

ein mehrzeiliges Dings,

was so ein bisschen eine Zwischenform ist

zwischen SQL und Python-Code.

Ja.

Aber ich spare