Transkript: PostgreSQL und MariaDB

Ja, hallo liebe Hörerinnen und Hörer.

Herzlich willkommen beim Python-Podcast, Episode 43.

Heute reden wir ein bisschen über Mimaria und Max und vielleicht ein bisschen über PostgreSQL.

Und haben natürlich wieder den Jochen da.

Hallo Jochen.

Hallo Dominik.

Ich bin der Dominik.

Und die Susanne ist heute dabei.

Ah, hallo Dominik.

Hallo Jochen.

Hallo Susanne.

Ja, haben wir News?

Wir starten immer mit ein bisschen News und ja, es war nicht so wahnsinnig viel.

Ich weiß nicht, ich kann ja einfach mal so erzählen, was ich irgendwie für bemerkenswert halte, was in der letzten Zeit so passiert ist.

Ja, auch im Hintergrund, Tippy.

Ja, ich mache hier auch schon mal die Kapitelmarken, dann spare ich mir ein bisschen Zeit.

Das hilft wahrscheinlich auch nicht.

Genau.

Ja, also was ist alles so irgendwie passiert?

Zum Beispiel, es gibt jetzt irgendwie PyTorch für Apple, für M1 optimiert.

Also es ist halt noch nicht so schnell, also es ist auch noch nicht wirklich vergleichbar mit Nvidia.

Aber tatsächlich geht da so ein bisschen was in die Richtung.

Also vorher konnte man schon ein bisschen was machen mit PlateML, aber jetzt gibt es halt auch tatsächlich direkt Unterstützung von PyTorch aus.

Und ja, das sah eigentlich schon mal ganz interessant aus und da geht bestimmt noch mehr in Zukunft.

Es ist auf jeden Fall jetzt gut zu sehen, dass es mal so ein bisschen in die Gänge kommt.

Das war jetzt ganz lange Zeit.

Also es ist jetzt auch, ich glaube 2020 oder so, sind die rausgekommen.

Das ist jetzt schon zweieinhalb Jahre her.

Ja.

Genau.

Das ist aber jetzt eher so eine Minor News.

Ja, außer man hat fast ausschließlich Apple-Hardware, so wie ich dann.

Das ist natürlich super wichtig, ja.

Ja, ansonsten, ich meine, wenn ihr mal dieses ganze Machine Learning-Thema und so interessant findet, letztens kann ich den Robot Brains Podcast empfehlen von Peter Wiel.

Und da war, äh, letzte Woche war da irgendwie Jeffrey Hinton zu Gast oder es hat, es gibt jetzt zwei Episoden.

Das war sehr interessant.

Also irgendwie quasi derjenige, der so die ganzen, oder einer von denen, die diesen Deep Learning Hype irgendwie so mit losgetreten haben.

Oder was heißt Hype ist ein bisschen, eigentlich ist er ja schon durchaus was hinter.

Und ja, der erzählte so ganz interessante Dinge.

Also ja, kann man sich ja mal vielleicht irgendwie anhören.

Ja, es gab, das ist jetzt schon ein bisschen länger her, ich habe ja jetzt eigenartigerweise erst davon erfahren, oder vielleicht haben wir das ja auch schon erzählt, das weiß ich nichts genau.

Es gab ein Paper in Nature.

NumPy ist jetzt tatsächlich als quasi Artikel irgendwie in einem renommierten Magazin erschienen.

Damals, äh, Travis Olyphont hat da ja da seine Doktorarbeit für abgebrochen und ihm haben alle gesagt, so bist du verrückt, irgendwie sowas Komisches zu machen.

NumPai, das interessiert doch niemanden.

Und ja, jetzt hat das doch nochmal auch akademische Weinen irgendwie gezeitigt.

Das ist gar nicht so schlecht spät, aber ja.

Tja, genau.

Sonst habe ich auch eigentlich nichts wirklich was.

Wir wollten nochmal vielleicht Büropyten haben wir ja schon ein paar Mal eingeladen.

Bist du jetzt eigentlich da?

Weiß noch nicht, weißt du.

Also ich schon.

Ich habe keine Unterkunft gefunden, jedenfalls nicht, sodass wir da alle hinfahren könnten.

Daher, wenn, dann bin ich alleine da.

Deswegen.

Kurzfristig, okay.

Ja, und kurzfristig könnte sein, dass das klappt, aber muss es halt nochmal gucken, weil Urlaubsplanungen anderweitige.

Also meine Unterkunft ist nicht weit von der Blue Dog-Bahn entfernt.

Das ist schon mal

ganz falsch.

Ich habe übrigens nachgeguckt, dass da gibt es keine Zimmer mehr.

Oh, ausgebucht.

Ja.

Okay, wow.

Hat er erst im Mai eröffnet.

Tja.

Okay.

Also, ja.

Tja, so ist das.

Na gut, dann sind wir heute mit den News dann relativ schnell durch, würde ich sagen, oder?

Ja.

Haben wir schnell gemacht.

Guck mal, so schnell waren wir nur nie, drei Minuten.

Obwohl, wir könnten auch noch irgendwie, es gibt jetzt auch eine Postgres 15-Beta, glaube ich.

Da könnten wir eigentlich schon eine Überleitung eigentlich ein Thema gleich vorhaben.

Was ist denn in der Postgres 15 Beta drin?

Weißt du das?

Weiß ich nicht.

Das sind er auch nicht?

Oh, okay.

Nee, das weiß ich jetzt auch nicht auswendig.

Da müsste ich auch nachgucken, was jetzt wirklich drin ist in der Beta und was nicht.

Ich könnte da jetzt zählen, wie das immer so funktioniert bei Postgres mit den Beta und den Releases.

Dann machen wir doch das, dann gehen wir da direkt über.

Dann machen wir doch genauer.

Hauptthema zum

Hier steht ja bei großartig steht Developer Experience and Performance.

Ja, also es gibt immer, bei Postgres musst du einen Patch einreichen, wenn du ihn geschrieben hast.

Einschließlich Dokumentation, ganz wichtig.

Und dann gibt es halt ein paar Reviewer, die da drüber gucken, das machen dann andere Entwickler.

Und dann kriegst du den Patch entweder, ich sag immer, du kriegst ihn zurück, also da kriegst du dann eine E-Mail, was mit dem Patch ist, ob der so in Kick gehst oder nicht okay ist.

Wenn du deine Klammer ans Ende gesetzt hast, das sind die neue Zeile, kriegst du den Patch, kriegst du den Patch zurück, weil da wird massivst drauf geachtet, auf solche Sachen.

Und wenn dann noch irgendwie eine Ausnahme ist, dass auf dem Maß ein Vulkan ausbricht, dann wird der Patch halt auch nicht angenommen.

Also wenn da irgendwas passieren könnte, was du nicht bedacht hast.

Und da Postgres ja überhaupt keine Kunden dahinter hat, die jetzt irgendwo Druck machen könnten, weil es ist ja eine kostenfreie Software, können wir natürlich auch recht früh sagen, also wenn wir sagen, okay, wir releasen und da ist jetzt noch irgendein neues Feature drin oder irgendein Patch drin, der noch nicht hundertprozentig ist, können wir den auch einfach zurückstellen.

Also wir haben da nicht den Druck, dass da jetzt irgendwelche Kunden sagen, der Patch muss jetzt aber unbedingt in die nächste Version, sondern das passiert auch schon mal, dass die so kurz vor knapp nochmal zurückgestellt werden und dann erst ins nächste Release kommen.

Das ist gar nicht so selten.

Das passiert ja.

Mittlerweile schaffen wir es immerhin, rechtzeitig zu releasen.

Das war auch schon mal eine Zeit lang nicht so.

Eigentlich wird immer ein neues Release rausgebracht zur Oscon, glaube ich, also zu irgendeiner amerikanischen Konferenz in der Regel im Oktober.

Also ich hatte das schon, dass ich im Linux-Hotel gesagt habe, es müsste bald, wir haben Oktober, es müsste bald ein neues Release rauskommen und zwei Tage später, noch während der Schulung, kam das neue Release raus.

Aber was genau drin ist, sieht man auch erst immer, also man sieht natürlich, was alles entwickelt wird, aber was da jetzt davon jetzt in das nächste Release kommt und was nicht.

Okay.

Das sieht man dann tatsächlich erst am Ende, weil da werden natürlich auch riesige Tests gefahren.

Und es gibt auch absichtlich dann, dass es nicht angekündigt wird, was drin ist.

Eben damit man nochmal sagen kann, wir stellen das eine oder andere nochmal zurück.

Deswegen wird das auch nicht so groß publiziert, was da jetzt.

Also wir publizieren jetzt nicht ein halbes Jahr vorher im nächsten Release kommt, das und das.

Sondern, das sieht man erst immer mit der neuen Version und den Release-Notes, was da passiert ist und was nicht.

Auf alle Fälle ab Version 13 ist PostgresQ nochmal wahnsinnig viel schneller geworden.

Also ich kann allen nur empfehlen, zumindest auf 13 abzugraden.

Wer noch auf 9.6 ist.

9.6 müsste auslaufen.

Ich richtig gerechnet habe jetzt gerade.

Ah, okay.

Ja, also ich würde sagen, aber jetzt haben wir dann die News auf jeden Fall durch.

Ja, ja, ja.

Und können wir noch anfangen mit unserem Thema?

Tja.

Und das Thema ist ja tatsächlich irgendwie so ein bisschen dann Datenpacken.

Im Speziellen, im Allgemeinen oder auch noch ein bisschen im Detail.

Du hast ja ganz viel Erfahrung mit Susanne.

Du kennst halt die ganzen Unterschiede zwischen Mühe, Maria, oder?

Soll ich das erzählen?

Also, ich habe, ich erzähle mal kurz die ganze Geschichte.

Ich habe mal irgendwann Informatik studiert vor gefühlten 100 Jahren.

Und damals an der Uni hatten wir Informix.

Und die Rechenzentren waren auch noch nicht so wirklich klimatisiert.

Und SSH gab es schon.

Erstmal fragen, was ist das Informix?

Informix ist ein kommertionelles Datenbanksystem.

Das gehört zu IBM.

Und ich hatte mir dann überlegt, ich war ja faul, wollte nicht immer ins Rechenzentrum, wie gesagt, SSH gab es schon und habe dann geguckt, wie ich zu Hause programmieren kann.

Und wie ich das Datenbanksystem dann nehme und es gab dann damals schon MySQL so ein bisschen und es gab ein bisschen PostgreQL.

Und PostgreSQL hatte mehr Ähnlichkeit.

Also da gab es schon irgendwelche Features, die gab es bei MySQL noch nicht.

Ich weiß nicht mehr genau, was es war.

Ich habe dann PostgreQL genommen und es war damals wirklich noch ziemlich identisch.

Ich habe später erfahren, PostgreSQL und Informix hatten denselben Urkurt.

Das war beides irgendwie an der Universität Barclay entwickelt.

Nein, das heißt, es gab einen, der das an der Universität Barclay, dieses Datenbanksystem entwickelt hat.

Ich weiß nicht, ob das auch schon Michael Stonebreaker war.

Ja, das war Michael Stonebreaker.

Ich komme nur nicht drauf.

Ingress heißt es.

Ich kam jetzt nur gerade so schnell nicht auf den Namen.

Also Michael Stonebreaker hatte dieses Projekt mit Ingress.

Michael Stonebreaker hat dann die Universität zweimal verlassen.

Ich weiß jetzt nicht bei welchem Mal, und mit dem Code zusammen und er hatte dann den Code irgendwie verkauft.

Deswegen hieß es dann, ist dann wieder zurück zur Uni.

Da er das nicht mehr Ingress nennen konnte, musste es jetzt Postgres heißen, also nach Ingress, Post für nach Ingress.

Und aus dem einen Mal, wo er es verlassen hat, samt Code ist dann später in Formix entstanden.

Also die basieren wirklich beide auf dem uralten Ingress-Code.

Und deswegen war das zu der Zeit noch, so 2099, 2000 war das noch ziemlich identisch.

Das heißt, du konntest auch so den Dampf vom einen in den anderen einspielen und so weiter.

Das war noch relativ, so unterschiedliche Features hatten sie nicht.

Ist heute natürlich nicht mehr so, nach 20 Jahren Weiterentwicklung.

Und so bin ich irgendwie da reingekommen in diese Postgres-Geschichte.

Dann hatte ich einen Job in PostgreSQL und ich hatte festgestellt, PostgreSQL kann was nicht.

Ich hatte im Studium gelernt, das ist irgendeine Update-Syntaxe, eine spezielle wäre Standard, aber Postgres konnte das nicht und dann hieß es, ja, entwickel doch.

Und ich hatte dann einen Mentor dazu, einen der großen Entwickler von PostgreSQL, mit dem habe ich mir ein Büro geteilt.

War stimmt gar nicht, der war im Nachbarbüro, aber wir haben zusammen in derselben Firma gearbeitet.

Und dann habe ich angefangen, an PostgreSQL mitzuentwickeln.

Und das fand PostgreSQL ganz toll, weil da hatte eine Susanne einen Patch eingereicht, ein weiblicher Vorname.

Und dann haben die also wirklich ganz große E-Mails rumgeschrieben, ob es noch eine zweite Frau gibt oder ob ich die erste wäre.

Und dann haben sie festgestellt, ich war die erste Entwicklerin, die ein Patch dann committed bekommen hat und in den PostgreSQL-Code.

Und das haben die, da haben die irgendwie so, waren die so stolz, so juhu, wir haben endlich eine Frau.

Das hat so ein bisschen Welle geschlagen.

Und dann habe ich aber irgendwie diesen Job.

Nein, da ist was passiert.

Und dann kriegte ich dann, ich brauchte einen neuen Job.

Und ich kriegte dann per ICQ, schrieb mich dann jemand an.

Wie das nochmal?

Oh oh.

Ich weiß es nicht mehr, aber es war der CEO von MySQL.

Der schrieb mich bei ICQ an.

Ich habe gehört, was passiert ist.

Du suchst doch bestimmt einen neuen Job, du kannst morgen bei uns anfangen.

Und ich stand da, ich habe von MySQL überhaupt, keine Ahnung.

Hallo?

Ja, das lernst du.

Und dann musste ich dann natürlich ein bisschen durch diesen ganzen, wir wissen noch nicht, in welcher Abteilung, aber wir nehmen dich an und dann, äh, wie kannst du bei uns anfangen?

Ich habe mir das dann natürlich erstmal überlegt und musste dann durch diese, so ein bisschen durch diesen Bewerbungsprozess durch mit erstes Interview auf Englisch.

Einer Frau aus Maine, die ich überhaupt nicht verstanden habe.

Mein späterer Chef sagte, das ist auch schwierig, diesen Dialekt zu verstehen.

Weil sie hatte mich nach irgendwas gefragt und ich habe ihr was völlig anderes erklärt, weil ich das Englisch nicht verstanden habe.

Naja, und

hat sie das gemerkt?

Sie hat mich einfach erklären lassen.

Natürlich.

Ich weiß gar nicht mehr, wonach sie mich gefragt hat.

Ich habe, glaube ich, Point-and-Time Recovery erklärt und sie wollte irgendwas anderes wissen, aber sie hat mich einfach erklären lassen.

Irgendwann hast du irgendwas Schönes doch gewusst.

Und ja, natürlich.

Sie wollte, glaube ich, nur so generell so ein bisschen abprüfen.

Und ja, dann war ich jahrelang bei MySQL, bis sie dann dun wurden.

Da habe ich auch noch mitgemacht und dann wurden sie Oracle.

Und dann bin ich mit vielen anderen Kollegen gegangen.

Das musst du nochmal genau erinnern.

Das war ganz.

Ja, also MySQL ist sehr, sehr schnell gewachsen.

Wir waren zum Schluss, als wir noch MySQL, also MySQL ist in Schweden gegründet, waren ein schwedisches Unternehmen weltweit, alle im Homeoffice.

MySQL ist tatsächlich auch einer der Vorreiter, was Homeoffice angeht, also echtes Homeoffice mit eigenen Büros und was man da alles beachten muss, ist nämlich gar nicht so einfach.

Und wir hatten, glaube ich, zum Schluss 400 Mitarbeiter, 200 Techniker, 200 Sales oder irgendwie so, so pi mal Daumen und Auge.

Und im Höhepunkt des Erfolges sind die dann für zwei Milliarden an Sun Microsystems verkauft worden.

Also da gab es dann auch natürlich, man hat dann wohl Geldgeber gesucht, das war dann so die Überlegung, machen wir jetzt eine IPO, also gehen wir an den Aktienmarkt, ganz offiziell.

Machen eine AG drauf im Grunde, würde man in Deutschland sagen.

IPO heißt das Ganze.

Ich weiß jetzt nicht, was IPO in Langform heißt.

Keine Ahnung.

Ist ein klassischer Börsendienstwendefirma.

Und dann haben sie aber beschlossen, sie verkaufen es die Aktionäre.

Es war ja schon irgendwie ein.

Haben dann beschlossen, sie verkaufen es an sein Microsystems für zwei Milliarden.

Zwei Milliarden, finde ich schon eine ganze Menge.

Initial Public Offering, ich habe die ganze Zeit.

Ja, Initial Public Offering, genau, genau.

Und dann haben sie es verkauft, dann sein Microsystems und ein Jahr später ist sein Microsystems von Oracle gekauft worden.

Und das könnt ihr euch vorstellen, dass wir mit Oracle jetzt, das war jetzt der größte Konkurrent eigentlich so.

In der Zwischenzeit hatte aber der Montevideius.

Hatte er vielleicht noch ganz vorher, also MariaDB war vorher Open Source gekonnt.

Nein, nein, MySQL.

Das war alles MySQL noch.

MariaDB komme ich jetzt zu.

Also der irgendwie in diesem Sun Oracle hatte der Montevideo, der Urentwickler, einer der Gründer, der Urgründer von MySQL.

Dessen Töchter dann auch.

Das sage ich zwar hier auch noch, genau.

Der hatte irgendwie den Code aber geforgt von MySQL, den er verforgen konnte, legal, und hat dann MariaDB gegründet.

MariaDB, weil er hat drei Kinder, M, also MY, aus Englisch Mai, Schwedisch eigentlich M.

Die jüngste Tochter heißt Maria und er hat noch einen Sohn, der heißt Max.

Es gibt auch ein Max.db, ich weiß nicht, ob das noch gibt, aber das war eine Datenbank, die unter SAP oder im SAP-Umfeld mit war.

Ich glaube aber, die ist mittlerweile ganz, die war schon fast eingestopft, als ich bei Myers Girl war.

Und also hat er gesagt, okay, das nächste System heißt dann Maria nach meiner jüngsten Tochter.

So ist das dann mit Maria.db gekommen.

Und auch die anderen Chefs, was ja immer häufig so ist, wenn eine Firma aufgekauft wird, wer gehen muss, sind die ganzen Geschäftsführer, hätte ich gesagt, oder die ganz, ganz hohen Chefs, so auch der von den ganzen Services, also Training, Consulting, Support.

Und der hatte dann damals eine Consulting-Firma gegründet, Sky SQL, weil sie hatten sich überlegt, sie wollten nicht mehr Entwicklung und die Dienstleistung in einer Firma haben.

Mittlerweile ist das wieder alles MariaDB, die haben dann das wieder zusammengelegt, aber sie wollten ja ein bisschen aus Erfahrung lernen.

Das ist so, dass so MariaDB, es sind ganz, ganz viele Kollegen damals von den Entwicklern zu MariaDB gegangen.

Also, ich weiß nicht, wer da noch bei Oracle heute ist.

Ich wüsste jetzt keinen, aber es heißt nicht, dass da keiner mehr ist, aber die

komplett einfach alle gekündigt und zum.

Ja, das war ganz viel bei diesem Sun Microsystems, Oracle kauft Sun Microsystems.

Ich weiß nicht, ob ihr das gehört habt.

Java zum Beispiel, die Java-Leute haben auch fast alle gekündigt, die OpenOffice-Leute haben fast alle gekündigt und MySQL halt entsprechend auch.

Wo sind die Java-Leute alle hingekommen?

Das weiß ich nicht.

Keine Ahnung.

Keine Ahnung.

Also wenn ihr es wisst, schreibt mal an hallo.de.

Ja, genau.

Und ja, so war das.

Und ich bin dann zurück zu meinen Wurzeln.

Ich habe mich dann mit einem Franzosen, mit einem Engländer, mit einem noch einem zweiten Deutschen und einem aus den USA und einem Italiener zusammengetan.

Und wir haben dann PostgreSQL erstmal.

Es war so ein bisschen gemischt.

Die Firma heißt Second Quadrant, ist jetzt Enterprise.db.

Und ich habe hauptsächlich Consulting gemacht, weltweit, für PostgreSQL.

Also ich bin ganz viel um die Gegend gefahren, geflogen mit dem Amerikaner zusammen und irgendwann wurde uns das zu viel.

Mir zumindest, weil wenn du ganz viel unterwegs bist, irgendwann machst du das nicht mehr.

Und dann habe ich gesagt, okay, ich muss kürzer treten, habe dann erst noch so ein bisschen promoviert und dann am Ende gesagt, eigentlich liebst du das Ganze und mach B ja bis heute im Grunde Postgres Girl und Maria.b als Consultant und Trainer, aber hauptsächlich halt, wo man gut hinkommt.

Also keine Langstreckenflüge mehr.

Ich brauche das nicht heute, Amerika, morgen Japan.

Also so, wo man gut hinkommt.

Das ist dann auch zum Beispiel Amsterdam ist näher als Bayern.

Oder so.

Nein, kann natürlich auch nach Bayern, so ist das nicht, aber es ist halt nicht so.

Das ist so das, was ich mache, ich war dann zwischendurch noch so ein Microsystems hatte noch die Idee.

Nein, die hatten das Angebot gekriegt von Ansi, von dem American National Standard Institute.

Genau, du wolltest mich erzählen, du hattest mich doch mal diese ganze Reisetätigkeit vorher im Zusammenhang da mit dem SQL-Standard gemacht haben.

Ja, Ansi, also Ansi ist an San Microsisten herangetreten und hat gefragt, ob sie jetzt nicht jemanden, da sie jetzt ja MySQL aufgekauft haben, ob sie nicht jemanden im Standardgremium haben wollen.

Ob wir nicht jemanden ins Standardgremium stellen können.

So, und bei Postgres war immer das Problem, das wollte der Standard nicht, weil das ja keine Legal Entity hat.

Also macht ja kein Geld.

Das ist ja irgendwie Open Source.

Da war etwas komisch.

Und dann hatte Sun auch noch Java.db und ich weiß nicht was, die hatten noch ein paar mehr Datenbanksysteme.

Und dann gab es irgendwo auf einer Konferenz ein Meeting.

Ich war nur per Skype zugeschaltet.

Und ich wusste auch gar nicht genau, weil wenn man in so einem Meeting per Skype zugeschaltet ist, du kriegst nicht wirklich mit, wenn die alle durcheinander reden, um was es da geht.

Und ich hatte dann irgendwie so meinen einen Kollegen Sergey, den hatte ich im IAC und ich hatte Sergei dann gefragt, um was geht es?

Und dann erzählte er mir groß, ja, die suchen jetzt jemanden, der uns da im Standardgremium vertreten kann.

Und irgendwie so eine Minute steht, hast du Lust?

Und ich sagte, ja.

Und dann hörte ich, dann hörte ich nur, dass Sergey sagte, ich habe da jemanden.

Also es muss so gesehen sein, dass Peter dann wohl von PostgreSQL, den hatten wir mittlerweile zusammengeholt.

Das war auch lustig.

Mein alter Kollege Peter Eisentraut, meuralter Mentor, der ist mir mehrfach gefolgt in mehrere Firmen, das ist ganz lustig.

Peter muss wohl auf den Monitor, auf alle Fälle hörte ich nur wie Peterstimmer, sondern oh ja, das ist eine coole Idee, da bin ich mit einverstanden.

Und dann war wieder Stille und dann hörte ich meinen Chef sagen, auch ohne dass mein Name bis dahin gefallen war.

Ja, genau.

Das ist perfekt.

Und dann hörte ich, wie alle anderen fragen, wie meint ihr denn jetzt?

Und dann kam raus, ja, Susanne.

Und so bin ich dann erstmal in diesem Ansi-Gremium gelandet.

Was sehr lustig ist in Amerika, weil man muss bei ISO sagen, so ein ISO-Standard funktioniert oder so ein Standard funktioniert so, du brauchst immer drei verschiedene Parteien.

Also ich sag mal, du brauchst einen Hersteller, du brauchst irgendwie eine Universität und noch was Drittes, also oder zwei Hersteller.

Wenn du drei Gruppen hast, kannst du erstmal einen nationalen Standard gründen.

Also bei DIEN, die brauchen auch immer drei und das dürfen nicht drei Universitäten sein.

Es muss schon irgendwo, irgendwer muss da schon mal Gewinn bringen mit was zu tun haben.

Und dann hast du einen nationalen.

Und wenn du dann irgendwie drei europäische Nationale hast, kannst du einen EN-Standard gründen und wenn du drei internationale hast, kannst du einen ISO-Standard gründen.

Irgendwie so.

Und im ISO-Gremium hat jedes Land nur eine Stimme.

Egal wie groß das ist.

So, jetzt das amerikanische Gremium.

In Amerika saßen natürlich sämtliche Datenbankherrscher, das ist eine riesengroße Gruppe gewesen.

Da saß auch Microsoft drin, die haben kaum was gesagt.

Im Grunde haben sich, sag mal, nur IBM versus Oracle die beiden da ausgemacht.

Und Oracle hat natürlich auch Leute, die nichts anderes den ganzen Tag machen, als sich neue Ideen für den Standard ausdenken, so ungefähr.

Oder versuchen dann die Features, die Oracle sich ausgedacht hat, in den Standard reinzubringen, so muss ich das mal höflich sagen.

Und IBM und Oracle saßen auch fast in jedem Land.

Aber wenn du bei Ansi bist, vertrittst du natürlich in dem ISO-Gremium auch die USA.

Und dann war ich dann auf diesem ersten internationalen ISO-Gri-Meeting.

Dann kam Deutschland auf mich zu und sagte, warum zur Hölle vertrittst du die USA?

Und dann haben die mich zu DIN geholt und dann habe ich halt ganz lange bei DIN mitgemacht.

Und weil die Länder machen immer die Vorschläge in dem ISO-Gremium, das kommt auch noch dazu.

Also, wenn du eine Idee hast, dann macht das Land einen Vorschlag und im ISO-Gremium wird dann abgestimmt, ob das genommen wird oder nicht.

Und das ist extremst politisch auch teilweise.

Also das ist nicht so einfach.

Da kann es dir passieren, dass es uns mal passiert tatsächlich, dass dann ein asiatisches Land gegen den Vorschlag von Deutschland gestimmt hat und dann fragte der Kanadier oder der Engländer, irgendwer fragte nach, warum?

Und dann kam ja, weil Deutschland in irgendeiner Schraubennorm gegen Japan gestimmt hat oder gegen das asiatische Land.

Ich weiß nicht mehr, welches genau war.

Also so, wir standen da, wir kannten diese Schraubennorm nicht mal.

Also vielleicht um nochmal genau den Hören zu erklären, worum es eigentlich geht bei so einem Standard.

Da geht es halt darum, welche Features so eine Datenbank haben muss, damit sie sich so nennen darf.

Nee, es geht darum, so ein bisschen Einigkeit zu haben.

Also zum Beispiel, dass die, dass du egal welches Datenbanksystem du hast, das vor dem SQL-Standard hatte jedes Datenbanksystem seine eigene Sprache.

Und da hieß dann auch nicht immer alles Select, wenn du jetzt was raussuchst, das konnte auch ein Feind sein, ich habe keine Ahnung, wie es hieß.

Und die hatten halt, es gab ja schon Oracle und die IBM und Postgres, das gibt es ja alles schon seit den 70ern.

Und dann hat sich Oracle und der Stonebreaker und einer von IBM, wenn ich das richtig weiß, die haben sich dann damals mal Ende der 70er zusammengesetzt und haben gesagt, okay, wir entwickeln dann mal eine gemeinsame Sprache, damit wir nicht auf jedem System wieder das komplett umprogrammieren müssen.

Und so ist dann der SQL-Standard entstanden.

Und ich sage mal, so ein Select ist ja zum Glück auf allen Datenbankensystemen funktioniert.

Ein Insert funktioniert auch meistens noch.

Das Grund SQL funktioniert meistens noch auf allen gleich.

Und nur in den Dialekten wird es dann, weil ich das am besten.

Ja, genau, in den Dialekten wird es anders und das kommt daher, weil natürlich diese Gremien, da wird dann einen Vorschlag gemacht.

Und du machst keinen Vorschlag, wenn du das nicht schon implementiert hast.

Also ich kann zum Beispiel sagen, die Limit-Geschichte ist ganz witzig.

Myersquell hat Limit erfunden.

Also Limit heißt, wenn ich was raussuche und ich mache am Ende Limit 1, dann kriege ich nur den ersten Wert raus.

Wenn ich mache 1,3, dann krieg ich, wirft er die ersten drei weg und er gibt mir den vierten Wert.

Weil der Offset dann drei ist.

Also, ne?

Super Syntax.

Postgres fand Limit total cool und hat gesagt, das implementieren wir auch.

Aber diese Limit 1,3, also X, Y, das ist jetzt ein bisschen arg kryptisch.

Und die haben es dann schon implementiert mit Limit X Offset Y.

Und dann hieß es, bringt das mal in den Standard.

Dann haben wir dafür einen Vorschlag gemacht.

Und das ist auch durchgegangen am Ende.

Und allerdings war dann in dem internationalen Gremium kam dann zu bedenken, ja, das wäre aber immer noch nicht die Syntax, wie SQL eigentlich aussehen würde.

Und die offizielle Syntax heißt jetzt, glaube ich, Fetch X Rose, X Next Rose Offset Y.

Ja, also das ist dann sowas.

Ja, ich glaube, MySQL oder MariaDB hat mittlerweile die Limit X, Y gibt es, glaube ich, auch nicht mehr.

Die haben das, glaube ich, auch auf Offset geändert, weil das zu kryptisch war.

Da bin ich mir aber nicht hundertprozentig sicher.

Im Moment müsste ich ausprobieren.

Aber so funktioniert halt das Standard.

Und was halt, wo man das halt merkt, wo alle schon was hatten, war bei sämtlichen Zeitgeschichten.

Wenn man ein Date bei Oracle eingibt, ist das immer mit Urzeit zum Beispiel.

Da merkt man schon, okay, das hatten sie vorher schon.

Und dann kann man natürlich als Datenbanksystem sagen, wir implementieren das nach.

Wir machen dann Alias draus oder ähnliches.

Aber zumindest das Uhr, das Grund ist erstmal dasselbe.

Ist ja so ein Insolfs-Stat, so ein normales Update-Statement, das funktioniert bei allen ziemlich gleich.

Und dann hast du irgendwann die Dialekte, wie du es so schön gesagt hast.

Aber Standard ist halt eine politische Geschichte.

Die treffen sich dann auch zweimal im Jahr.

Immer ein Land lädt ein.

Und je nachdem, welches Land einlädt, will sich dann auch hervorheben.

Dann hast du dann so Meetings auf Hawaii.

Oh nein.

Auf Kreta.

Ja, sagst du so.

Welche Insel?

Welche Insel?

In Deutschland hatten wir mal überlegt, das auf Sylt zu machen.

Kommst du natürlich super hin.

Wir waren dann am Ende doch in Berlin, weil das DIN-Gebäude in Berlin bot sich an.

Wir waren auch in London, weil auch da haben die gesagt, das bietet sich an.

Das ist schon ganz schön.

Das ist natürlich teuer.

Weil die Reisen musst du ja auch irgendwo bezahlen.

Und Standardisierung ist ein spannendes Thema, ist halt ja.

Wenn man weiß, wie es funktioniert.

Und Amerika kam immer mit 15 Leuten auf diese internationalen Meetings, weil es konnte ja passieren, dass bei den Diskussionen irgendwas dann entschieden werden musste, wo das Land eine Stimme abgibt und damit die dann überhaupt eine Mehrheit hatten.

Und Deutschland, wir waren da meist zu zweit, es war noch die Uni Aachen damals mit in dem Gremium, als ich da drin war.

Die haben mir gesagt, wenn ihr beide euch einig seid, einer von Orekel und ich, dann passt das schon, so ungefähr.

Und auch die anderen Länder waren kleiner.

Aber wie gesagt, IBM und Orekel, die saßen fast in jedem Land, hatten die.

Das war schon sehr spannend.

Und Postgres wollten sie immer nicht haben oder nicht annehmen, weil es war ja rein Open Source, da gab es keine Legal Entity und so weiter und so fort.

Mittlerweile sitzt der Peter tatsächlich im Standardgremium in Deutschland, glaube ich, auch.

Also wir haben dann immer Peter sowieso schon mit dazu geholt von PostgresQL.

Der hat eine Zeit in Finnland gelebt und den haben wir aber immer beratend schon mit dazu gehabt, weil wir Deutschen hatten eigentlich nichts dagegen, wenn Postgres mit drin ist.

Weil ich habe offiziell ja MySQL vertreten.

Oder MariaDB.

Nee, MySQL tatsächlich nicht MariaDB, weil es wurde ja von Oracle bezahlt.

Und natürlich hat das Gremium aber mich auch eher dann zu PostgresQL befragt.

Weil das war hinterher, als es Oracle war, dann ganz lustig, weil eigentlich mussten die von Oracle jetzt MySQL mit vertreten.

Und irgendwie kannte ich dann MySQL doch besser als die und war nie immer sehr froh, dass ich da noch mit drin war, aber irgendwann bin ich dann da ausgestiegen, weil ich dann auch nicht mehr, ja, das war auch, wie gesagt, das ist eine teure Angelegenheit.

Und mittlerweile ist der Peter Eisentraut da mit drin, dann brauche ich dafür Postgresquelle nicht mal rein.

Und wenn MariaDB da jemanden drin haben möchte, dann, da ich nicht bei MariaDB arbeite.

Ich weiß nicht, ob einer von MariaDB irgendwo im Gremium sitzt.

Weiß ich jetzt nicht.

Aber das war eine spannende Geschichte, mal zu sehen, wie so Standardisierung funktioniert.

Und ich finde es dann ganz lustig, weil SQL heißt nämlich nur SQL.

Das ist auch eine sehr lustige Geschichte, die ist bei Wikipedia ganz spannend.

Die hatten, ich hatte vorhin gesagt, vor dem Standard hatten die alle eigene Sprachen.

Und die von IBM hieß SQL.

Und das Gremium hat dann beschlossen, sie nennen diese neue Sprache, die sie da entwickeln, SQL.

War natürlich ein bisschen angelehnt an das IBM SQL, aber war es nicht.

Was war das ein Sequence Query Language?

Gar nichts, das heißt einfach nur SQL.

In dem steht immer bei Wikipedia, weiß ich Standard Query Language, Streckschart-Query Language, irgendwie so war es.

Und es wird dann, wir schreiben dann immer schon, im Englischen ist das lustig, wir schreiben dann in die Diskussion immer schon rein und ändern das und schreiben dann rein, passt nicht und so, hier siehe Standard heißt nur SQL.

Dann steht es drei Tage auch richtig drin und dann ändert es wieder einer.

Im deutschen Wikipedia steht es, glaube ich, mittlerweile richtig drin.

Also das ist auch so von wegen, wie funktioniert Wikipedia?

Wenn man dann da steht und denkt, so, ich hab's erfunden.

Das ist, glaube ich, auch irgendwem anderes mal passiert, irgendeiner berühmten Person, die hat dann irgendwas geändert zu sich selbst.

Das hat Wikipedia wieder zurückgeändert, weil sie meinten, sie kennen ihn besser als er selbst.

Kniffliges Problem, genau.

Wer ist da autorisiert?

Deswegen ist Wikipedia auch.

Ich erkläre das immer bei Studierenden, deswegen ist Wikipedia auch keine zitierwürdige Quelle, wenn die so wissenschaftliche Arbeiten schreiben müssen, weil das jeder ändern kann und weil du dann auch solche Phänomene hast.

Ja, ganz viel dazu.

Interessant.

Spannend mal die Geschichte vom Datenbanksystem.

Ja, wir können natürlich sowohl Postgres als auch Maria, also ich mache überwiegend heute Maria.b und PostgreSQL, selten noch das Original MySQL, weil das Original MySQL gibt es natürlich bei Oracle immer noch.

Ich habe aber das Gefühl, irgendwo ist meine Kundenwolke, die die dann in dem Bereich MariaDB einsetzt.

Also weniger das echte MySQL.

Weil MariaDB ist immer noch, die Lizenz ist Open Source.

Du kannst es.

Hat sich da in der Lizenz nochmal, aber die hatte MySQL hat ja so ein bisschen früher eine etwas komische Lizenz, ne?

Das war, oder im Vergleich zu anderen, also jedenfalls im Vergleich zu Postgres.

Postgres ist ja sehr liberal.

Postgres hat eigentlich ja.

Die BSD-Lizenz, das heißt, du kannst es einfach nutzen und gut.

Deswegen ist ja auch Postgres, findest du ja auch manchmal an ganz lustigen Stellen.

Das findest du dann in irgendwelchen Autos, in irgendwelchen Waschmaschinen oder in irgendwelchen Geräten, ich weiß jetzt nicht, auf einer Waschmaschine jetzt wirklich.

Aber da ist dann häufig, häufig ist auf solchen Geräten ein abgesprengtes NetBSD drauf, wegen der BSD-Lizenz.

Und dann, wenn so ein Datenbanksystem wirklich brauchen, dann eine Postgres auch wegen dem BSD, wegen der Lizenz.

Auf der Apple Watch ist SQL Lite wird auch oft gern verwendet.

Also wenn die Schritte gezählt werden, das macht auf der Apple Watch macht das eine SQL Lite.

Aber ja, Postgres auf einer Uhr ist vielleicht auch ein bisschen übertrieben.

Ich darf nicht so unbedingt über Referenzen reden, aber es ist schon spannend, wo Postgres da so überall drin sitzt.

Deswegen MySQL MariaDB, die sage ich immer, oder MySQL hat sich damit immer gebrüstet, vor allen Dingen Oracle, MySQL, die weltverbreitetste Datenbank, ich weiß das gar nicht, weil Postgres würde ich, ich würde das nicht unterschätzen, was da so auf den Geräten ist, wo du nicht als Mensch dran bist.

Natürlich, MySQL MariaDB ist unter Webseiten nicht wegzudenken.

Und du hast ja heute auch in den großen Firmen, du hast ja alles im Einsatz.

Also wenn ich mir mal meinen lieben alten Kollegen Christian Köntopf anhöre, was der da an Datenbanken, wie viele Systeme, der bei seiner Firma, wo er heute arbeitet, im Einsatz hat, das ist ja ganz viel auch von den NoSQL-Systemen, das wird ja alles gemischt.

Ganz viel auch mit den Adobe, Adobe, Apache, Apache, HBase und wie sie alle heißen und Neo4j und weiß ich nicht.

Das wird ja tatsächlich auch sinnvoll eingesetzt.

Nimm das Datenbanksystem oder nimm, mach nicht alles im Relationalen, mach das im Relationalen, was du im Relationalen abbilden kannst.

Und wenn du was Graf, Graf, was du besser in Grafen abbilden meinst, bildest ein Graphen ab.

Sowas wie Kunden, die auch X, die X gekauft haben, haben auch XY gekauft.

Das ist eher in so einer grafischen Datenbank aufgehoben als in einer relationalen.

Ich würde auf diese beiden Punkte gleich nochmal irgendwie eingehen.

Ja, aber genau, also da, ähm, ich finde Postgres ist eigentlich immer ganz schön, oder sagen wir so, ja, weil es halt so ein bisschen ähnlich ist, also ich meine, ich mache ja so einen, wenn ich Webentwicklung mache, meistens ja sowas Django-mäßiges oder halt, ich mag diesen Batteries-Included-Ansatz eigentlich da sehr gerne.

Und ich finde, Postgres ist das so ein bisschen für die Datenbankwelt, so was so Django für die Web oder Ruby and Rails für die Webwelt ist, ist halt so, weil, also es ist zwar jetzt vielleicht nicht in allen Sachen Spitze, aber es kann halt, also fast alles, was man so braucht, ist da schon mal drin.

Und man kann das einfach so verwenden.

Und ja, für viele Sachen ist es halt auch gut genug.

Vorsicht.

Tatsächlich, wenn ich so objektiv, ich kann ja objektiv sein, weil mir ist das ja ganz egal, was du einsetzt.

Und ich kenne ja jetzt beide, also ob jetzt Maria oder Postgres einsetzt, ich kenne ja beide Systeme sehr, sehr gut.

Und ich gucke mir tatsächlich, wenn mich jemand fragt, ich gucke mir an, was wollen die machen, was ist das für ein Kunde?

Natürlich erstmal, da gibt es ganz viel, da ist das völlig wurscht, ob du Postgres oder MariaDB nimmst.

Es gibt da so Eckpunkte, wo man dann sagt, okay, das ist vielleicht eher da besser und das ist das besser.

Aber was ich mir auch angucke, ist dann teilweise die Menschen, die es hinterher bedienen müssen, weil auch das ist etwas, der eine kommt mit Postgres besser zurecht und der andere kommt mit Maria.db besser zurecht.

Das finde ich jetzt spannend.

Welchen Nasenfaktor gibst du in Maria?

Welchen Postgres?

Postgres ist, es kommt darauf an, wo du herkommst.

Also von welchem Datensystem, auf welchem Datenbasensystem hast du gelernt?

Wenn du jetzt wirklich aus der DB2 in Formex im IBM-Ecke kommst, ist Postgres häufig für dich intuitiver.

Wenn du aus der Oracle-Ecke kommst, möchtest du vielleicht auch Postgres, aber nicht, weil es intuitiver ist, sondern weil die Migration einfacher ist.

Wobei ich das heutzutage auch mal dahingestellt lasse, du kannst auch zu MariaDB migrieren.

Wenn du jetzt wirklich aus der Webentwicklung kommst.

Alter LEMP-Stack, oder?

So PHP, was weiß ich, ja, LEMP, ne?

Ist vielleicht MariaDB für dich intuitiver?

Also es kommt ein bisschen darauf an, wie hardcore hast du SQL gelernt?

Auch.

Also sage ich jetzt mal ganz trocken.

Oder auch, an welcher Uni hast du SQL gelernt, weil die SQL-Kurse sind ja häufig auch schräg.

Also wenn ich mal so habe ich das gut ausgedrückt?

Ja, ich habe da wirklich schon, wenn ich so junge Menschen, wenn die so lernen, SQL oder Datenbankvorlesungen, es ist schon sehr spannend.

Dann hat man so ein reinen Oracle-Dialekt teilweise.

Was würdest du denn empfehlen, um überhaupt SQL zu lernen?

Vielleicht nochmal.

Also wenn ich SQL-Kurse gebe, jetzt für Anfänger, also für Grundkurse heißt das ja, ich mache Standard SQL.

Also ich erzähle dir auch erstmal nicht, dass es in Postgres ein Datentyp Text gibt oder ähnliches, sondern ich mache wirklich erstmal Standard SQL und mache wirklich die Standardsachen, weil die funktionieren wirklich bei allen.

Kennst du irgendwelche besonderen Tools, die man vielleicht noch verlinken könnte?

Achso, du meinst jetzt für Leute, die das grafisch machen wollen?

Ja, oder nicht unbedingt grafisch, aber einfach so als Kontext drumherum.

Wenn du bei mir SQL lernst, dann musst du das natürlich selbst runterschreiben.

Ja, das finde ich super.

Aber genau das ist ja vielleicht, also ich habe zwei tolle Sachen entdeckt im Netz, die mir da sehr geholfen haben.

Und zwar eins, ein Detektivspiel, wo man irgendwie einen Mordfall aufklären musste.

Gefühlt mit SQL.

Das war ein SQL-Tourist.

Das will ich sehen, genau das finde ich cool, weil ich finde Gamification ganz toll.

Wenn du bei mir die Schulung buchst, dann kriegst du dann Bindfaden und darfst dann an der Pinnwand mit Bindfaden und Moderationskarten rumspielen, damit das ein bisschen lustiger wird in der Gruppe oder so.

Aber ich erkläre auch Normalisierung.

Das ist ja auch so ein Thema, was immer noch ist.

Das müssen wir auch gleich nochmal machen, das finde ich nämlich auch interessant.

Das machen wir aber auch gleich, glaube ich, nochmal extra Normalisierung.

Das ist halt nur, wenn du so teilweise die ganz jungen Menschen, wenn die so SQL in der Uni oder wo auch immer in der Ausbildung bei der IAK oder so, teilweise, wenn du da reinguckst, ich werde ja dann häufiger auch mal nach Hilfe gefragt von jungen Menschen, so ganz unabhängig.

Und was ich da teilweise sehe, wo ich dann denke, okay, wir schlucken mal.

Das ist jetzt aber ganz stark Ore Kelastik oder ganz stark Mayersko Elastik hast du auch.

Häufig, was ich traurig finde in der heutigen Datenbank Ausbildung ist, also ich weiß jetzt nicht, wie es jetzt in der Pandemie kann sich das ja geändert haben.

Ich glaube das aber nicht.

Also, die letzten Datenbankvorlesungen, die ich gegeben habe, ich habe mich dann tatsächlich mich da mal reingekniet und mir auch die anderen angeguckt, weil die sind seit 2007 auf dem Markt.

Und ich kann nicht mehr nur relationale Datenbanken machen, wenn ich es lerne, sondern ich sollte vielleicht auch mal sagen, was ist eine grafenbasierte Datenbank oder eine dokumentenbasierte, dass man das zumindest mal vorstellt und mit reinmacht.

Du musst jetzt kein GQL und SQL.

Ich glaube, das ist für so ein Informatikstudium, wenn du es hinterher nicht brauchst, das ist halt Datenbank ist ein Pflichtfach.

Das ist ja sowas.

Nur, dass du es zumindest mal gehört hast, das finde ich halt sehr wichtig, dass man nicht nur immer auf die Relationalen eingeht.

In der Ausbildung.

Ich mache natürlich hauptsächlich Relationale, weil das ist mein Thema.

Zum Anfang, ich habe es rausgefunden, und zwar ist das SQL Mörder Mystery.

Ah ja.

Das ist das Erste.

Da geht es halt darum, den Modfall, also Mörder in SQL City.

Die muss man aufklären und dafür lernt man halt die ersten Queries zu machen, wer war denn in welcher Straße, wann wie wo.

Und dann du, das ist sehr interessant.

Das muss man halt auch schreiben dann, die Querys selber.

Ich habe eine Zeit lang auch mal irgendwie sowas gemacht, stell dir vor, du bist in deiner Küche und dann durftest du deine eigene Küche, wo sind die Teller und so weiter.

Das habe ich auch schon mal gemacht, ja.

Aber das finde ich cool, ja.

Und ich habe noch ein zweites Story mal gemacht, das ist ja auch das schlimmer, Select Stars, SQL heißt das, da geht es darum, die, das ist ein bisschen traurigeres Thema, aber die Gefängnisinsassen in Texas, die zum Tode verurteilt waren, auszuwerten, was denn deren letzten Worte waren und warum und so.

Ja, aber da gab es dann auch ein.

Ich habe gerade bei den Psychologen, die Psychologen-Statistik sollten dann irgendwelche BWL-Statistiken machen, Umsatzstatistiken und so weiter, wo die Psychologen dann da standen, was ist das eigentlich alles?

Also weil das so BWL-lastig war.

Und dann habe ich auch, ich hatte denen halt im Tutorium geholfen.

Und dann habe ich dann aber die eine Aufgabe gegeben, ich glaube, es war eine Umsatzstatistik, habe ich die Sterbestatistik draus gemacht.

Es war dann auch zwar Makaba, aber es war für die leichter Nachvoll zu vollziehen, als irgendwas BWL-Lastiges.

So, was passiert jetzt, wie viele Menschen sterben da jetzt vorne?

Deswegen, also da muss man immer gucken, was man für ein Publikum hat.

Und das ist in der Ausbildung halt sehr, sehr schwierig, weil am besten findest du natürlich Beispiele, die auch alle kennen.

Deswegen nehme ich immer gerne, ich habe es aufgegeben, das Kochbuch zu nehmen, weil so ein Kochbuch, so eine Kochbuch-Datenbank ist recht komplex.

Vor allen Dingen heutzutage, also früher habe ich immer gesagt, es googelt, es sucht niemand in einer Datenbank nach, gebe mir alle Rezepte mit dem Teelöffel oder wo die Menge fünf ist.

Brauchst du aber heute doch einzeln, normalisierst du tatsächlich auch aus heutzutage, weil Rezeptdatenbanken hast du natürlich heute auch den Anspruch dran, ich will das mal für zwei Personen kochen, mal für vier Personen, dann wird mit den Mengen gerechnet, dann musst du die Mengen wieder einzeln.

Aber nach wie vor sucht natürlich keiner nach, gib mir alle, wo Teelöffel drin vorkommt oder so, oder Messbecher oder Tasse oder was man immer eine Prise, ich meine, alle Rezepte und eine Prise drin.

Ein Quäntchen Glück.

Ja, aber deswegen, aber Kochbuch ist schon eine recht aufwendige Datenbank, das kannst du dann so als Prüfung mal verkaufen.

Aber dann willst du meistens auch noch irgendwas, was dir noch ein View oder ähnliches, dann ist ein Kochbuch wieder auch zu viel.

Ich glaube, dass wenn du so eine volle Datenbank hast, mit dir interessant ist, dann ist du lernen vielleicht besser, also wenn das nicht nur so trockene BBL-Daten sind, weil man dann vielleicht selber Neugier bekommt, auch mal in andere Datensätze reinzuschauen und dadurch, dass man das dann selber eintippen muss, dann halt lernt, wie die Syntax ist, um die Sachen so zu filtern, wie man das macht.

Du nimmst halt irgendwas Kleines als Beispiel und machst dann aber mittlerweile auch schon sowas wie Datensicherheit mit rein oder Datenschutz.

Du musst ja heute hast du ja auch sowas wie Transparenz und du musst ja, wer hat was, wann, wie geändert und so weiter auch noch mit festhalten.

Ja, aber gut, wenn ich SQL schreibe, ist das eigentlich nicht mit drin.

Das muss ich ja mit einem Meter.

Nö, das kannst du ja mit, wann du die Zeile geendet hast, du on Update, da machst du noch eine Spalte mehr dran und sagst dann, hältst du das dann ein Fest Last Update.

Genau, aber

das muss ich ja im Modell mit drin stehen haben.

Ja, ja eben, deswegen, das sind dann aber so Sachen, da gehst du dann vielleicht nochmal drauf ein, wenn du so, also dass du ein bisschen mehr auf Datenschutz eingehst.

Du machst immer dieses Beispiel, was in Transaktionen stell dir vor, du willst dem jetzt 100 Euro überweisen und das muss natürlich auf beiden Konten sein oder auf gar keinem.

Ich kann nicht sagen, bei dir sind 100 abgezogen und bei dir sind sie nicht angekommen, wenn das in der Zwischenzeit.

Das erklärst du immer noch, aber das weiß auch jeder, dass du das in der Praxis nicht machst.

Noch so ein Thema, das müssen wir gleich nochmal kurz.

Transaktionen, das müssen wir gleich alles nochmal aufmachen, da können wir uns die Reihenfolge überlegen.

Aber ja, zum Einstieg, ist dir noch was eingefallen, wie man das am besten lernen kann oder was du denkst?

Tja, ich hab, ich weiß es nicht genau.

Ich habe vielleicht eine pessimistische, äh etwas pessimistische Ansicht dazu, dass man, ich glaube, ich weiß nicht, ob man das, ob man das so trocken lernen kann.

Also ich bin ich einfach nicht der Typ dafür, ich kann das nur lernen, wenn ich das tatsächlich brauche.

Und es dauert auch lange.

Es ist nicht so, dass, also von irgendwie, ich habe angefangen, mich mit diesem Thema zu beschäftigen zu, ich fühle mich einigermaßen sicher.

Das waren bei relationalen Datenbanken eher so Jahre.

Und das waren, das ist, wenn man jetzt eine Semester eine Vorlesung hört und eine Prüfung schreibt, das ist aus meiner Sicht nicht so richtig gut möglich.

Jemand ist jetzt aber wieder verstehen, dass wenn Jochen meint, dass er so einigermaßen nicht wohl fühlt, ist ja derjenige, der es richtig aus dem Schlaf dann an.

Nein, nee, einfach so, dass man halt ungefähr weiß, was man da tut.

Dann hatte ich einen guten Prof.

Also ich habe jetzt relativ fest, aber tatsächlich merke ich, dass.

Das Spannende an SQL ist das Spannende an Mengenlehre ist.

Ich hatte ja in der ersten Klasse noch Mengenlehre.

Du musst ja nur so verklären, bitte, was das Mengenlehre ist.

Mengenlehre war in der ersten Klasse, du hast da so Ovalen gemalt, einen links, ein rechts, das war deine Menge.

Menge mit den roten Plättchen und das war deine Menge mit den blauen Plättchen.

So.

Und dann wolltest du jetzt wissen, ja, gib mir alle Plättchen, die die drei Ecken haben.

Und dann hast du die übereinander gelegt, dann hast du die Schnittmenge.

Aus dem roten und dem blauen Plättchen mit der Schnittmenge, die drei Ecken haben.

Die Rotanila.

Nein.

Dann hast du da die viereckigen drin und die Fünfeckigen und die Kreise hast du da beides.

Die Dreieckigen waren halt die Schnittmenge.

Das ist Mengenlehre.

Das nennt man auch so, boah, wie heißt das?

Kombinatorik heißt das dann im Studium.

Oder Butcher Algebra, nee, Kombinatorik ist es.

Mit A und B und nicht A oder B und solche Geschichten, genau.

Und ich sage immer, SQL besteht ja fast nur aus Mengenlehre.

Du hast ja, ne, entweder hast du die Schnittmenge Joinen, ein einfacher Join ist ja ein innerer Join ist ja nichts anderes als die Schnittmenge.

Und ein Outer Join ist immer irgendwie eine Menge plus der Schnittmenge.

Oder halt irgendwie, je nachdem, wenn du das natürlich negierst, oder gib mir nur das eine oder das andere.

Gib mir alle Werte, die aus Tabelle A, die nicht in Tabelle B stehen.

Das wäre jetzt auch ein Outer Join mit einem Nicht drin und so weiter.

Also es basiert immer irgendwie, kommst du am Ende immer auf Mengenlehre.

Also SQL ist ganz viel Mengenlehre.

Und jetzt habe ich den Faden verloren, was war deine Frage?

Ja, ich wollte kurz, dass du über die Mengenlehre sprichst, weil du gesagt hast, dass die Mengenlehre drinsteht.

Aber du hast vorher was gefragt zur SQL.

Also wie man sich das verbunden hat.

Achso, ja genau, genau.

Und ich habe halt im Studium und auch später, wenn ich mal junge Menschen ausgebildet habe.

Es gab, du hast dieses, entweder du hast dieses logische Verständnis für diese Kombinatorik oder du hast sie nicht.

Also ich hatte immer, wenn ich Prüfungen abgenommen habe und bewertet habe, ich hatte nur mal Einsen und Fünfen.

Also nur so ungefähr, es gab keine Mitte.

Und dann kommen dann so einige Institute auf die Idee, du musst ja jetzt seine Noten nach der Normalverteilung verteilen.

Und da ist ja super, du hast nur welche, ich habe es verstanden und nicht.

Da kannst du dann auf leider eine Nuance, vielleicht 1,3 oder 1,7 draus machen oder halt, nee, ne?

Das ist dann immer sehr schön.

Macht man heute zum Glück nicht mehr mit der Normalverteilung, mit den Noten.

Wüsste ich jedenfalls nicht, aber ich weiß nicht, ob das angeboren ist oder wie auch immer.

Ja, vielleicht wäre es interessant.

Vielleicht Leute, die in der ersten Klasse sowas wie Mengenlehre hatten.

Das war in meinem Studium, ich habe ja Informatik erst angefangen zu studieren, da war ich schon 28.

Und da gab es dann natürlich auch schon Menschen, weil das wurde nur in den 70ern in der Grundschule in der ersten Klasse unterrichtet.

Das war eigentlich keine schlechte Idee, muss ich sagen.

Aber da haben sich so viele Eltern, also man hat es in Niedersachsen und in NRW unterrichtet, ich weiß nicht wo noch, da haben sich so viele Eltern, da waren die Eltern so massiv dagegen, weil sie das nicht verstanden haben, weil sie ja nicht kannten.

Und dann hat man es wieder aufgegeben und jetzt fängt man dann wieder mit Zellen an.

Also Zellen kamen erst nach der Mengenlehre so ungefähr.

Oder was man heute in der ersten Klasse Mathe macht, ich weiß es nicht.

Oder in Rechnen heißt das ja, aber wir hatten halt Mengenlehre.

Und im Studium habe ich dann festgestellt, also es gab ja die, die das nicht mehr in der Schule hatten, in der ersten Klasse.

Und es gab auch noch einen Teil, der das in der ersten Klasse hatte.

Und mir war im Studium aufgefallen, das mit der Kombinatorik, die ist natürlich viel umfangreicher.

Mit diesen ganzen A und B und Oder B und so weiter.

Die machst du ja in Mathe im Studium.

Und brauchst du ja auch dann später zum Beispiel für SQL, Kombinatorik.

Und die hatten weniger Schwierigkeiten damit, die standen da.

Das ist ja wie Mengenlehre, so ungefähr.

Es ist nur ein bisschen, das sind nicht mehr nur Rot und Blaue und bunte Plättchen hast und Dreiecke und Vierecke, sondern du hast dann auch komplexere Sachen da hast.

Aber im Grunde, während die anderen, die Jüngeren, hatten damit mehr Probleme, weil sie das halt nicht schon aus der ersten Klasse kannten.

Das war mir so aufgefallen in der Mengenlehre.

Nein, die Frage deswegen, also weil vielleicht konnte man sich ja vorbereiten zu sowas, indem man nochmal sich so diese Basismengenlehre, wie du sagtest, mit den unterschiedlichen Schnittmengenkreisen vor Augen führt, um dann zu überlegen, wieht das in der SQL aussieht, weil so jemand, der sowas noch nie gesehen hat, der irgendwie einen komplexeren Autodreunten ein bisschen sacheln sieht, der ist vielleicht so ein bisschen.

Deswegen mache ich ja auch bei den, ich habe da auch eine Folie für, wo ich wirklich das wie in der Schule mit den Ovalen, ich nenne das immer Aja, mit den Ovalen und Schnittmenge und was ist A und B, A oder B oder A und nicht B und solche Geschichten.

Sehr lustig ist immer, dass das funktioniert bei MariaDB nicht so ohne weiteres.

Es gibt mir dann alles aus A und B, nur nicht die Schnittmenge.

Das ist dann ein lustiges Query.

Wenn man das in einer Anwendung braucht, ist dann was anderes, aber nur damit man dann mal die Logik dahinter aufersteht.

Aber es gibt halt, meine, ich weiß nicht, ob das eingeboren ist oder woher.

Es gibt ja auch beim Programmieren, wenn ihr so Algorithmen habt in einer Programmiersprache.

Da ist mir auch schon aufgefallen, dass es da Menschen gibt, die können der Logik nicht folgen.

Warum auch immer.

Die haben aber dann ganz, ganz tolle andere Fähigkeiten, die ich nicht habe.

Aber das ist dann.

Naja.

Und nein, aber bei SQL ist es wirklich so, du kannst da nicht so viel falsch machen.

Also wenn du es verstanden hast, hast du es verstanden.

Und was du dann vielleicht machen kannst, ist diese Normalisierung, was du vorhin schon sagtest, aber auch das, wenn du das einmal verstanden hast, dann ist das nicht das.

Vielleicht jetzt richtig Zeit, um nochmal drauf einzugehen, was der Normalisierung überhaupt ist.

Da gibt es halt, glaube ich, verschiedene Ebenen von oder Stufen, wie man die machen kann.

Also wenn ich das so leihhaft richtig verstanden habe, ist das das Aufbrechen einer ganz komischen Tabelle in die richtige Form, wo halt die einzelnen Tabellen voneinander getrennt werden, wenn Informationen redundant vorhanden sind.

Und die verbindet man dann halt über Foreign Keys oder sowas.

Also es gibt das jetzt erstmal, ich will es jetzt nicht so ganz mathematisch erklären.

Du hast ja es gibt verschiedene Grade von Normalisierung.

Es gibt die erste Normalform, die zweite Normalform, es gibt die dritte und noch folgende: Vierte, fünfte, sechste, ich habe keine Ahnung.

Normalerweise normalisierst du nach der dritten Normalform.

Das ist so das übliche, ich kann dir jetzt auswendig nicht aus, nicht sagen, was die erste und die zweite ist.

Ich muss das jedes Mal nachgucken, wenn ich es, wenn ich es schule, weil du brachst immer nur am Ende die dritte.

Im Grunde geht es darum, das ist eigentlich ganz simpel, du möchtest zum einen keine doppelten.

Also wenn ich jetzt.

Also in zwei Spalten irgendwo eine Adresse steht, dann möchte ich die nicht zweimal drin haben, sondern eine eigene Adresse, eine Tabelle mit Adressen.

Ich hätte jetzt gesagt, Stadt.

Ich hätte jetzt gesagt, ich hätte es noch weiter runtergebrochen, so Postzahl Stadt, das Klassische, was du so in einer Tabelle hast, aber wir nehmen mal nur den Städtennamen.

Ich komme jetzt aus Bielefeld und ich habe vorher mal in Osnabrück studiert.

Ich habe mittlerweile einen Anschlag von, haben sie erst vor zwei Wochen in China getestet, von 675.

Osnabrück schaffe ich nie richtig zu schreiben.

Ich schreibe immer Osaanbrücke.

675 ist der Rekord, fand ich nicht?

Ja, und Bielefeld schreibe ich auch immer falsch.

Und wenn ich jetzt aber irgendwie eine Tabelle habe, wo ich jetzt eine Adresse drin habe.

Also ich habe dann irgendwo die Adresse und ich will jetzt alle Leute suchen, die in Bielefeld wohnen.

Und ich habe da Bielefeld fünfmal falsch geschrieben, dann finde ich die natürlich nicht, die ich falsch geschrieben habe.

Und um das zu vermeiden, macht man halt eine Tabelle Städte.

Da hat man nun das Wort Bielefeld einmal drin stehen.

Und dann hat Bielefeld vielleicht die ID 33615, weil das die Postzahl ist.

Und oder wonach man das auch immer nur bei Städten wäre es Postzahl, wäre eine super ID, kann auch eine andere Nummer nehmen, die 67.

Und dann steht halt bei der Tabelle mit der Person unter Stadt nur 67.

Und dann kann man das verlinken und sieht dann, ah, die 67 ist Bielefeld.

Das ist einfach, das ist eine Sache, damit man sich nicht verschreibt, damit man es nicht irgendwo dann nicht wiederfindet, dass man halt immer dasselbe hat.

Und wenn man dann in der Städtetabelle nicht Bielefeld, sondern Bieleflat geschrieben hat, dann ist das halt überall Bielefett.

Also das ist das.

Einfach zu ändern.

Wenn man es löschen, gibt es Bielefeld plötzlich nicht mehr.

So ungefähr.

Wie kann das denn sein?

Ja, okay.

Ich hätte auch Düsseldorf nehmen können, aber Düsseldorf tippe ich nicht so häufig.

Da vertippe ich mich noch nicht so häufig.

Aber Bielefeld und Osnabrück ist noch schlimmer zu tippen.

Du trippst immer Osahnbrücke.

Das ist tatsächlich irgendwo so der klassische Tippfehler.

Und das andere ist die Sache, dass du das zusammenpackst, was zusammengehört und nicht mehr.

Dann nehme ich jetzt den Küchenschrank.

Du hast in deinem Küchenschrank vielleicht eine Schublade, wo die Teller drin sind.

Oh, da drauf ist noch die Küchenwaage und die Küchenwache ist umbegreht und in die Schale von der Küchenwaage war es noch ein Messbecher.

Du hast einen Ort, wo deine Teller sind.

Du hast einen Ort, wo deine Gläser sind.

Ich hatte mal eine Mitarbeiterin, die hat tatsächlich beim Ausräumen der Spümas.

Nein, ich hatte meine Mitarbeiterin, die hat beim Ausräumen der Spülmaschine das einfach immer in irgendeinen Schrank gestellt und dann standen dann die Teller und die Tassen irgendwie so alle durcheinander und ich habe nichts mehr wieder gefunden.

Und nein.

Also du sortierst ja es noch ein bisschen in deinem.

Du sortierst in deiner Küche, ich habe jetzt die Küche genommen, ich hätte auch deinen Kleiderschrank nehmen können.

Du sortiert das ja ein bisschen.

Und du hast vielleicht einen Schrank, wo nur die Gläser drin sind.

Da hast du Weingläser drin, Biergläser drin und so weiter.

Aber das ist der Schrank, wo nur die Gläser drin sind.

Und dann hast du einen Schrank, dann nehmen wir die ganze Wohnung, da sind nur deine Unterhosen drin.

Die schmisch du nicht.

So, ne?

Wenn du das mischen würdest, wäre das ganz lustig.

Aber das ist erstmal so, dass du das so weit runterbringst, dass du das, was zusammengehört, diese Einheit, machen wir mal die Einheit-Teller oder was in diesem Küchenschrank ist.

Du kannst auch sagen, ich habe die Küche mit den Küchengeräten, wäre jetzt sowas.

Und da habe ich das Schlafzimmer, da liegt das, du hast ja auch nicht unbedingt deine Kleidung in der Küche liegen.

Also du kannst auch zimmerweise das machen, je nachdem.

Aber dass du diese Einheit hast, in die du das runterbrichst.

Aber das finde ich jetzt interessant, weil ich glaube, das ist relativ schwierig, weil ich stelle mir das jetzt so vor, dass da relativ viel Validierung nötig ist, das da reinzubekommen, weil beispielsweise habe ich jetzt einen Schrank, wo Gläser reinkommen, aber ich möchte jetzt dann vielleicht doch teilen zwischen Weingläsern und Biergläsern oder was sagen.

Ich kann es ja halt weiterbellen.

Aber woher weiß ich denn jetzt, ob was ein Weinglas oder ein Bierglas oder ein.

Das hast du ja irgendwo definiert.

Ja.

Also du kannst es auch anders machen.

Wir nehmen mal Autos.

Autos haben eine Farbe.

Autos haben eine Marke, Autos haben einen Typ und so weiter.

So.

Und die haben einen Preis.

Du willst jetzt so eine Autowebseite machen, wo du dein Auto verkaufen kannst.

Jetzt stell dir vor, du packst alles alle Informationen des Autos in eine Tabelle.

So, und jetzt will ein Käufer danach suchen.

Er möchte jetzt nur in meiner Automarke nur Mercedes haben.

Ein bestimmten Typen noch ein bestimmtes Baujahr.

Und dann überlegt sich der Käufer, okay, also du musst dann alles aus dieser einen Tabelle raussuchen.

Dann überlegt sich der Käufer, naja, eigentlich möchte ich nur diesen Typen haben von dem Auto.

Jetzt steht der Typ da immer wieder in dieser Tabelle drin.

Du hast ja keine zweite Tabelle, wo der Typ drin steht und hast da nur die Nummern drin.

Auch noch fünfmal falsch geschrieben, wahrscheinlich.

Mercedes vielleicht auch noch dreimal falsch geschrieben.

Du hast alles in einer Tabelle.

Das wird sehr, sehr schnell.

Wird die Tabelle sehr, sehr breit.

Auch bei der Farbe gibt mir alle roten Autos.

Frauen suchen ja gerne, habe ich mal gehört, nach der Farbe der Autos.

Weiß ich jetzt gar nicht, ob das habe ich noch nie ausprobiert bei solchen Sachen.

Gib mir alle roten Autos, aber theoretisch geht das wahrscheinlich.

Praktisch geht das wahrscheinlich auch.

Aber erstmal wird die Tabelle ziemlich breit und du bist da ein Zug.

Also breit hast viele Spalten.

Also du hast halt viele Informationen zu dem Auto.

Es hat vier Reifen, es hat vielleicht noch die Reifentypen und so weiter und die Reifengröße und was weiß ich, was man da Baujahr und wie alt Tachostand und alles Mögliche.

Und wenn das alles in eine Tabelle und dann sucht jemand einen Möchtenkäufer haben, der jetzt bestimmte Eigenschaften da raussucht.

Ich kann ja sagen, das wird sehr, sehr groß.

Es gab in der Vergangenheit eine Plattform, die was ähnliches gemacht hat.

Und die hatten wirklich nur eine Tabelle.

Und die haben mit Hardware skaliert.

Weil sie das nicht mehr anders skaliert haben.

Und die sind auch dann ein wenig in finanzielle Not geraten, weil die Hardware dann irgendwann nicht mehr bezahlbar war.

Okay.

Immer teurer mehr

Geld aufgeschrieben.

In der Zwischenzeit waren aber ein paar Kollegen von mir da, die hatten erst, glaube ich, eine Oracle-Datenbank.

Ich wusste davon nichts.

Als ich dazukam, waren sie dann mittlerweile, weil sie keinen Kurs gegangen waren, von einem großen IT-Unternehmen aufgekauft worden, das ganz viele dieser Plattformen aufgekauft hat.

Und ich durfte dann nach London zu diesem großen IT-Unternehmen.

Und dann wollten sie, sie wollten damals von MySQL nach PostgreSQL migrieren.

Und sie hatten immer noch diese eine große Tabelle.

Und ich habe dann gesagt, naja, das liegt nicht an dem Datenbanksystem, was ihr da drunter habt.

Das liegt an dem Design eurer Datenbank.

Das solltet ihr mal ändern.

Ihr werdet mit Postgres genau das gleiche Problem kriegen wie mit Maria.db.

MySQL war es damals noch.

Und ich bin dann nach Hause gefahren und dann kriegte mein britischer Kollege einen Anruf, der sollte die Consultant verschessen.

Hat ja nicht das gesagt, was ich hören wollte, so ungefähr.

Ja, schick mal einen anderen und mein britischer Kollege hat dann einen ganz Jungen dahingeschickt, weil er meinte, naja, ich werde auch nichts anderes sagen als du.

Und ich habe mich dann ohne überhaupt irgendwie einen Namen zu nennen, weil das ist ja auch immer gefährlich so zu Hause, man hat ja auch Geschäftsgeheimnis und so weiter.

Ich habe das dann zu Hause, ich habe mich bei meinem Mann darüber aufgeregt, über diesen Kunden, ohne ihn zu benennen.

Ich weiß jetzt nicht, ob mein Mann wusste, bei welchem großen Kunden ich war.

Also ich, er wusste jedenfalls nichts von dieser Plattform.

Und ohne dass ich das jemals erwähnt hatte, sagte mein Mann dann, das war die Plattform.

Ich so, woher weißt denn du das?

Und dann hat er mir das erzählt, dass zwei sehr bekannte MySQL-Consultants da damals schon mal waren.

Da wollten die von Oracle nach MySQL migrieren und die beiden hatten auch.

Der erste hatte gesagt, naja, das liegt nicht an Oracle, das liegt an eurem System.

Und dann war der, aber hatte dann bei MySQL dann auch Consultant ist scheiße, dann ist der andere hingefahren, auch sehr namhaft und bekannt.

Der hat das dann auch nochmal gesagt und ich glaube, ein dritter war dann auch nochmal da.

Der hat gesagt, hatte gehört, was sie vorher beraten hat und gesagt, oh ja, ja, im Leben.

Nee, nee,

das brauchst du gar nicht.

Das brauchtest du gar nicht, das war so offensichtlich.

Und naja, okay.

Und dann hatten die nie wieder was davon gehört, bis ich dann da war.

Und ich kriegte dann am Ende einen Anruf von dem großen Unternehmen und wurde dann gefragt, nur so irgendwie eine Stufe höher, was denn da los war.

Und dann habe ich das erzählt.

Und dann haben die wirklich diese Plattform ein halbes Jahr aus dem Netz genommen und komplett neu programmiert.

Die Plattform gibt es heute noch, ist aber komplett anders.

Aber das passiert, wenn du alles in einer Tabelle hast und wenn du da so viele Informationen drin hast, wenn du dann so Spalten, wenn du dann 250 Spalten hast in einer Tabelle, das macht auch nicht mehr wirklich Spaß, die Informationen daraus zu suchen.

Die willst du auch nicht mehr lesen und nicht mehr warten.

Ja.

Das ist, äh, MariaDB hat irgendwo ein Spaltenlimit bei, ich weiß nicht wo, 256 oder so.

Wenn du das erreichst, ich habe so Tabellen gesehen.

Wenn das dann nur noch hoch scrollt an Spalten, das ist überhaupt nicht mehr wartbar.

Also, mal abgesehen davon, dass da ganz komische Artefakte passieren, aber irgendwann denkst du dir schon von dir aus, okay, es ist vielleicht sinnvoll, diese Tabelle mal mehrere aufzuteilen.

Ja, das vielleicht unter Kategorien zusammenfassen.

Ja, genau.

Also, und das Normalisieren heißt einfach, du fasst es irgendwo so zu Kategorien zusammen oder das zusammen, was zusammengehört.

Wenn du jetzt das klassische Wikipedia-Beispiel zur dritten Normalform oder überhaupt zu den Normalformen ist immer Musik, die haben dann immer Interpreten, Alben und Songtitel.

Kann man jetzt den Lieblingsinterpreten draus machen, was auch immer.

Wenn du jetzt natürlich eine Tabelle hast, da steht dann fünfmal Helene Fischer, dumm, fünfmal die Ärzte, kenne ich mehr Titel.

Und da steht dann 127 Mal oder wer weiß, wie viele Songs die Ärzte gemacht haben, da drin.

127 Mal die Ärzte und daneben steht dann, sagen wir, erstmal, wie viele Songs sind auf so einem Album?

30 mal das eine Album, dann das andere Album und dann die Songtitel nochmal.

Dann hast du schon 127 Zeilen, wo du die Ärzte doppelt zigfach drin hast.

Das machst du ja nicht nur mit einem, das machst du dann ja mit deiner ganzen Plattensammlung oder deiner ganzen Song-Sammlung und dann hast du eine riesige Tabelle.

Also, was machst du da?

Du machst natürlich als erstes mal, du nimmst erstmal die Interpreten raus, machst du von der eigene Spalte, hast eine Interpretenspalte.

Kannst du leider nochmal die Adresse oder wo du dann die Autogrammkarten kriegst oder was auch immer, je nachdem, warum du jetzt die Musiktitel sammelst, noch mit dazu parken, einen Ansprechpartner oder ähnliches von der Band.

Aber die packst du in eine Tabelle, die kriegen eine ID.

Diese klassische Personen-ID, die lässt du automatisch generieren, haben die halt so, was weiß ich, die Ärzte ist vielleicht Nummer eins.

Und dann steht in deiner Song-Tabelle nur noch die Eins drin für die Ärzte und die 2 für Rammstein und die 3 für irgendwas.

Und die 27 für Helene Fischer oder sowas in der Richtung.

Also hast du noch die Nummer und du kannst dann nachgucken, wenn du dann in der Tabelle bist, okay, interprete Nummer, was hatte ich vorhin?

Drei?

Und dann guckst du in der anderen Tabelle nach, Nummer 3 ist, habe ich vergessen.

Hatte ich überhaupt eine 3?

Weiß ich nicht mehr.

Aber eine 2 bei Rammstein, das weiß ich noch nicht.

Ja, die 3 ist ein Seputura irgendeine Metalberg.

Ja, egal.

Nur dass du dann halt nur noch über die Zahlen das machst.

Dasselbe machst du mit den Alben.

Weil ja auf so einem Album, du willst ja den Titel haben am Ende, ne?

Wir sind ja bei dem Titel im Grunde.

Aber die Alben, auf so einem Album ist ja immer auch mehr als ein Song drauf.

Also lagerst du die Alben auch aus.

Da kannst du noch eine Verknüpfung machen, Album und Band, sondern Zwischentabelle.

Dass du das Album und die Band noch zusammenlegst, dann hast du auch noch das, hast du nicht bei dem Album immer noch die Band stehen, sondern du machst eine Zwischentabelle, wo du das Album und die Band reinpackst und dann hast du dann ab 18 ist vielleicht bei den Ärzten, das erste Album hat die ID 1, ist von den Ärzten und dann steht dann in dieser Zwischentabelle nur noch 1.1 drin.

Album 1, Interpret 1.

Und dann kannst du das so zusammenfügen.

Ziehst du halt alles ein bisschen auseinander und dann hast du halt nur noch die Tabelle mit dem Titel, wo dann drauf steht Album 1, Band 1.

Achso, da hättest du es sowieso drin, dann brauchst du es gar nicht.

Oder nur Album 1 und dann kannst du es dann nochmal weiter verlinken.

Wenn du da jetzt nochmal das doppelt, aber das macht man schon, dann denormisiert man dann schon mal leicht.

Aber das wäre so, dass du es ein bisschen sortierst, dass du es halt kleiner machst.

Wenn du es aber zu klein machst, es macht keinen Spaß, Kombinationen aus Datenbanken zu suchen, wenn du dabei weißt, wie viele Tabellen hast.

Also bei über 8 wird das irgendwo spannend.

Es macht dann auch nicht mehr wirklich Spaß, die alle zu verjoinen.

Dann fängst du dann an, gezielt zu denormalisieren.

Ich hatte das jetzt gerade schon gemacht, indem ich dann halt gesagt habe beim Titel, okay, das ist auf Album 1 und auf dem Interpreten 1.

Es hätte ja gereicht, der Interpret steht ja schon mal beim Album.

Den hätte ich gar nicht so doppelt drin gehabt.

Aber das wäre so eine leichte Denormalisierung schon.

Und das erklärt man auch immer gerne.

Beim Kochbuch habe ich das früher erzählt.

Niemand sucht nach Teelöffel.

Das heißt, du kannst bei der Menge auch sagen, 200 Teelöffel, äh, 200 Teelöffel, 200 Gramm oder so.

Da ist es auch egal, ob du Gramm groß, klein oder nur GR schreibst oder wie du Teelöffel abkürzt, ist auch völlig egal, weil da sucht keiner nach.

Heutzutage ist es aber nicht mehr so, dass du in die Menge beim Kochbuch einschreiben kannst, 300 Gramm Mehl.

Du hast Mehl und dann 300 Gramm, wenn du jetzt die Zutaten zusammenmischt, weil du ja diese Funktion hast, ach, gib mal jetzt für zwei Personen oder drei und teilmann, dann brauchst du plötzlich nicht mehr 200 Gramm, sondern 150 oder so.

Da musst du dir schon ein bisschen mehr wieder überlegen, aber vom Prinzip her, wo du da mal gezielt Bottlenecks auch dir angucken kannst und sagen kannst, okay, den normalisiere ich jetzt bewusst.

Du machst aber nicht mehr als die dritte Normalform.

Alle anderen sind eher universitär und unübersichtlich.

Also so ein bisschen.

Also die ein bisschen tiefer gehen halt, wo dann alles geht.

Ah, also die dritte Normalform ist eigentlich das, was du am Ende brauchst.

Und du brauchst immer einen Schlüssel.

Jede Datensatz sollte einen Schlüssel haben.

Es ist ganz lustig, wenn du Datensätze in einer Datenbank hast, die keinen Schlüssel haben.

Und da steht dann in der Datenbank fünfmal drin, Volkermeier, Adolf Straße 27 in Düsseldorf.

Jetzt hast du den Datensatz aus Versehen fünfmal erfasst.

Er sieht aber identisch aus, komplett.

Fünfmal.

Du willst, aber du wirst ihn eigentlich nur einmal haben.

Du musst ja jetzt die vier da rauskriegen.

Wie kriegst du denn die da raus?

Das ist schon eine lustige Aufgabe, passiert manchmal.

Ich weiß, wie man es rauskriegt.

Aber alleine schon deswegen ist es sinnvoll, dem Ganzen auch noch eine Kennung zu geben, irgendeine Eindeutigkeit.

Und deswegen hast du meistens dann, meistens heißt die Spalte dann auch ID.

In den meisten Datenbanken heißt die dann ID, dass du eine Spalte davor sitzt, wo du dann eine Kennung rein hast.

Und dann hast du dann, Nummer 1 ist Klaus Meier, Nummer 2 ist Klaus Meier, 3 ist Klaus Meier, 4 ist 5 ist Klaus Meier, dann kannst du dann sagen, Delete alle, wo Name Klaus Meier ist oder alle mit ID 2 bis 4.

Könntest du ja auch so machen.

Dann hast du da eine Eindeutigkeit, jede Spalte sollte eine Einligdeutigkeit haben.

Jeder Datensatz sollte zumindest in einer Spalte eindeutig identifizierbar sein.

Und das ist dann meistens der primäre Schlüssel, über den du die auch finden kannst und über den du diesen Datensatz auch bearbeiten kannst, über diesen alleinigen.

Das ist, dass noch was dazukommt.

Und dann hast du die dritte Normalform, du brauchst ein Primär-Key und du musst Primary Key, Primär-Key heißt das auf Deutsch, ne?

Primärschlüssel heißt das so.

Und du solltest es halt so ein bisschen ordentlich sortieren, dass du nicht alles in einer Tabelle hast.

Okay, und wenn man dann davon weggeht, dann schreibt man halt alles rein.

Was?

Ich würde sagen, eine Malisierung haben wir, glaube ich, soweit verstanden, oder?

Ja, also, genau, also ich meine, irgendwann, also ich habe dann irgendwie meistens, wenn du dann bei irgendeinem neuen Problem oder so, da oft dann angefangen, so ein Entity-Relationship-Diagramm hinzumalen oder so.

Und das, äh, genau, das macht man dann eigentlich meistens irgendwann, hat man das dann so ein Gefühl, wie das dann aussehen kann.

Tatsächlich auch.

Also dass ich mir das grob auf irgendeinem Schmierzettel aufmale und wenn ich es nicht, wenn es nicht nur drei Tabellen sind, das kriege ich im Kopf und hin.

Aber tatsächlich mache ich das auch tatsächlich, dass ich mir das dann teilweise mal auf dem Schmierzettel überlege.

Wie ich da eigentlich immer dran gehe, ist, wenn ich eine Datenbank neu aufsetze, ist, ich gucke erstmal nach, was muss ich überhaupt alles an Informationen in dieser Datenbank speichern.

Ja, genau, also.

Also wirklich so als reines Sammelsurium, das ist natürlich für andere Firmen programmierst du das so, musst du das erstmal aus den ganzen Besprechungen raus haben, was brauchen die überhaupt alles in der Datenbank.

Dann musst du noch gucken, meistens für die Firma mit, was ist überhaupt erlaubt, abzuspeichern.

Gibt es ja auch sowas, sowas wie diesen bei der Kreditkarte, diesen, nee, bei der EC-Karte hinten die Nummer, die darfst du, glaube ich, gar nicht mit abspeichern.

Oder solchen Sachen.

Dass man da nochmal guckt und man muss ja immer versuchen, man hat ja in der Regel nicht mit IT-LAN zu tun oder mit technischen Menschen, sondern mit anderen, aus deren Sprachgebrauch herauszufinden, was davon kann ich denn überhaupt als Daten abspeichern, als Information.

Und das sammle ich dann einfach auch immer erstmal ganz wild durcheinander und sortiere das dann.

Und dann überlege ich mir, wo könnte ich jetzt was davon hinpacken und was gehört da wie zusammen.

Und so baue ich das Ganze auf und dann gucke ich, wie kann ich das dann vernetzen.

Und auch ich mache es so, ich mache auch immer erstmal die dritte Normalform und gucke dann, gut, manchmal sieht man dann schon auf Anfang an, okay, da könnt ihr ein Bottleneck haben, da können Sie was reinhaben.

Ich kann mal ein Beispiel nennen für ein Bottleneck, eine Spielefirma mit Online-Spielen.

Die haben mehrere Online-Spiele.

Und natürlich hat der Nutzer nur einen Account.

Und dann hat er auch Nick der Nutzer.

Aber die sind hinterher dazu übergekommen, weil jetzt von diesen mehreren Millionen Nutzern musste natürlich immer die Account-Tabelle aufgerufen werden, um dann irgendwas über den Nutzer rauszufinden.

Bei den Spielen, so darf der das Spiel, wie weit ist der der Spielstand oder so weiter.

Und die mussten dann immer den Nutzer, und wenn da auf eine Tabelle immer laufend zwei Millionen Sachen draufkommen oder noch mehr Spieler, ist das natürlich etwas schwierig.

Und dann sind die hingegangen und haben die nix der Spieler dann nochmal in den Spielen hinterlegt.

Dass die nicht immer auf die eine Tabelle zugreifen konnten.

Deswegen ist das ganz häufig so, Passworte ändern ist meistens einfach.

Und ganz viele, ich weiß nicht, ob es immer noch so ist, ich spiele so selten, aber den Nick ändern ist immer etwas schwieriger und aufwendiger.

Das liegt daran, dass das dann nicht nur in der einen Tabelle, sondern weil die den nochmal denormalisiert haben und zwar aus Absicht, weil das einfach sonst zu viel wird auf einer Tabelle.

Okay, da muss man dann tatsächlich zurückgehen auf diese Tabelle gucken.

Ja, ja, und dann dann, deswegen ist so ein Nick-Ändern bei so Spielen häufig ein häufiger Mal so ein Problem gewesen, eine Zeit lang.

Ich weiß nicht, ob es immer noch so ist.

Aber das wäre so ein Beispiel für eine gezielte Denormalisierung.

Aber das ist halt das.

Ja, also dann, wenn ganz viele Zugriffe auf eine Tabelle sind, dann muss man vielleicht drüber nachdenken, ob man die

vielleicht nicht.

Was ich auch mal aus Versehen denormalisiert hatte, war so eine Stempelu Datenbank.

Da habe ich einen Start und einen Stopp.

Stempeluhr ist ganz einfach.

Ich habe eine Startzeit, ich habe eine Stoppzeit.

Und ich habe dann noch clevererweise die Differenz mit abgespeichert, weil das war dann einfach okay, wenn ich das dann, wenn ich Stopp sage, kann ich auch gleich nochmal eben schnell die Differenz Stopp minus Start ausrechnen und das auch mit abspeichern.

Das war dann auch meine Riesenrettung, weil ich habe dann als Admin tatsächlich mal irgendwo ganz schnell wollte ich, obwohl es da Skripte für gab, noch irgendeine Stoppzeit nachtragen und habe die Werkklausel vergessen.

Und dann alle geupdatet.

Genau.

Auch komisch, warum dauert das Update dann so lange?

Na, das ging relativ schnell, das war ein guter Server.

So viele Mitarbeiter waren das nicht, aber dann so, ja, die Stempel lief auch erst irgendwie so zwei Jahre, also das war nicht nur schlimm.

Ja, aber zum Glück, weil zum Glück gab es die Differenz noch.

Also konnte ich dann ganz schnell mal ein Update fahren, mach mal Stab plus Differenz und dann hatte ich wieder die richtige Stoppzeit drin.

Also das kann auch mal passieren.

Wobei ich da auch dachte, okay, eigentlich ist das ja, hättest du die Differenz ja gar nicht gebraucht, aber ich fand das damals sinnvoll, sie mit abzusprechen und ich errate das auch beim Stimmblo jeden ist da mitzumachen.

Doppelt hätte besser dann dir.

Nee, das ist es auch teilweise, wie du es in der Anwendung brauchst.

Wenn du immer Differenz brauchst brauchst, dann brauchst du auch nur die Differenzabfragen und musst nicht immer Start und Shop abfragen später in der Anwendung.

Ja, genau.

Das ist dann auch noch was, das musst du ja auch noch wieder ein bisschen mit dazu tanken.

Und du musst natürlich heutzutage auch so ein bisschen Sicherheit, Datenschutz und was weiß ich, was mit berücksichtigen.

Deswegen hast du auch ganz viel in den Tabellen, was jede Abteelle noch last updated und so weiter mit in jeder Speicher.

Updated.

Ja, ja, irgendwie sowas.

Oder hast du noch eine History-Tabelle, wo die alten Werte reinkommen oder ähnliches.

Das hast du ja auch noch.

Ein Model

History Tracker.

Ja, das hast du ja auch bei Preisen.

Wenn du jetzt ganz normal so eine Verkaufstabelle machst, dann hast du ja auch bei Preisen häufig wie wenn Preis änderst, solltest du ja den alten Preis ja auch nochmal irgendwo sie.

Ja, schon praktisch, dann kann man dann noch in die Entwicklung gucken.

Ja, nicht nur das, weil du änderst vielleicht heute den Preis, aber es haben noch nicht alle die Rechnungen bezahlt und dann brauchst du ja noch in einem Jahr solche Geschichte.

Das ist lustig, es gibt auch Unternehmen, da wird dann der Preis bezahlt, der jetzt gerade aktuell gilt.

Das ist auch lustig, was auch immer mal wieder passiert, ist so ja für die Schlüssel, dass dann die Namen genannt werden.

Ich hatte mal eine Firma, die hätte wirklich bei den Mitarbeitern als Schlüssel die Namen.

Ich so, was macht ihr denn, wenn ihr Mitarbeiter habt, die gleich heißen?

Das ist ja minus zwei.

Haben wir nicht, stellen wir nicht ein.

Also das sollte man natürlich nicht machen, sondern weil bei Mitarbeitern, also bei sowas nimmt man meistens auch die Kennung.

Es gibt natürlich auch natürliche Schlüssel.

Ich weiß nicht, ob Autos jetzt das Kfz-Zeichen unbedingt sinnvoll ist, als Kennung zu nehmen, aber es gibt halt so Schlüssel, so ISBN-Nummern oder sowas, die könnte man auch als Schlüssel nehmen.

Oder wenn man jetzt die Postleitzahlen hat oder Postleitzahlen sind auch super Schlüssel bei Städten oder ISP.

Was ist das denn von

den Daten dann?

Das ist schon sehr sinnvoll, wenn das so eine Ganzzahl ist, irgendwie jedenfalls.

Je nachdem, was man für einen Index verwenden will, vielleicht da drauf.

Aber so im Normalfall denke ich schon, dass es vielleicht nicht so unpraktisch ist.

Ja, das ist halt so eine Frage.

Das wäre eine interessante Frage.

Also irgendwie sehe ich in letzter Zeit sehr häufig, dass Leute UI-IDs verwenden, irgendwie automatisch.

Ich nehme gerne auch den Unix-Timestamp für bestimmte Dinge auch.

Ja, also irgendwie in der JavaScript-Welt ist das halt so total super, was ich in gewisser Weise verstehen kann, weil da hat man ja oft irgendwie nur das, wenn man jetzt IDs erzeugen möchte, dann will man ja, dass sie eindeutig sind, hat aber keine zentrale Datenbank, möglicherweise.

Es gibt

halt diese Sache bei Postgres bei Maria, die wir uns so weit haben.

Sogar im Standard gibt es denn da ein Typisch Serial, der soll einfach immer einen hochzählen.

Und das kann man natürlich machen.

Und wenn das völlig egal ist, dass du eine Nummer hinterher hast, nimmst du den und zählst dann einfach immer.

Dann zählt der automatisch beim Einfügen einen hoch und dann hat das Ding eine eindeutige ID.

Auto-Increment dann ja.

Ja, Auto-Increment heißt das bei MySQL, bei PostgreSQL, nimmst du den Datentyp Serial oder genau, und dann macht er das automatisch.

Ja, also ich weiß nicht, ich habe dann irgendwann mal Benchmarks gesehen.

Also ich meine, das macht das halt, weil einfach Yu Yo-ID ist halt so riesig.

Das heißt, wenn du, wenn du das dann tatsächlich als Primary Key hast, dann macht das halt Joints bei Postgres.

Das letzte, was ich gesehen habe, so viermal langsamer oder sowas.

Bei den meisten ist das halt wurscht, weil irgendwie Datenbank ist vielleicht leider eh nicht, das Bottleneck, aber also ich meine, es kostet halt viel mehr Speicher und es macht Dinge langsamer, daher tendiere ich immer dazu zu sagen, hey, lieber eine Zahl nehmen.

Und dann, wenn man sowas haben will, wie so eine Eigenschaft will man ja oft haben, dass man nicht sehen kann, wann ein Datensatz eingefügt worden ist, weil bei einer Zahl kann man das natürlich sehen oder welche miteinander zusammenhängen oder so, dann kann man sowas wie Hash-IDs im Frontend verwenden, wo man das dann, wo man die IDs hasht, aber das sozusagen den Hash in der Datenbank zu verwenden, weiß ich nicht.

Ich tatsächlich häufiger mal als Kundennummern oder so auch Timestamps gesehen habe.

Genommen ab.

Das ist natürlich, wenn du dann so ein Support am Telefon, nennen Sie mir mal Ihre Kunden-ID und dann fängt er an, so ein Unix-Timestamp zu lesen nimmst.

Gut, du erkennst es als Laie nicht als Timestamp.

Da musst du schon Freak zu sein, dass du raffst, dass das ein Timestamp ist, von wegen Eindeutigkeit und schwer zu raten, aber ist halt auch eindeutig, dass du dann irgendwie so in derselben Sekunde mehrere Kunden anliest, ist dann doch schon schwierig.

Also so viel.

Nee, kommt auf dein Business drauf an.

Kann natürlich sein, im Online-Business würde ich das vielleicht jetzt nicht machen, den Timestamp nehmen, aber wenn du jetzt so eine normale Firma hast.

Dann John, also das kannst du auch machen oder wie du dir noch immer generierst.

Du musst dir halt was überlegen.

Und ganz häufig bei den Tabellen ist es einfach automatisch hochgezählt.

Macht wahrscheinlich dann Sinn.

Und wie gesagt, Postleitzahlen sind recht eindeutig.

Oh, aber das ist doch eine interessante Sache, weil was mache ich denn jetzt, wenn ich die Postleitzahlen-Eingabe nicht kontrollieren kann, weil ich die irgendwie herbekomme.

Und dann hat irgendjemand dann D-Postleitzahlen angegeben oder sowas.

Und dann habe ich ja das Problem, dass ich dann doppelt habe quasi.

Naja, das kommt ja darauf an, wie du die Postleitzahlen in der Datenbank abgelegt hast.

Ja, du in Waler.

Ja, nein, dann geht es halt kaputt an der Stadt.

Also ich würde sowas ja prüfen in der Software, bevor ich es an die Datenbank schicke und die Datenbank prüft es und wirft es dir zurück, weil.

Das ist einfach.

Weil ich muss ja erstmal, also ich nehme die Daten entgegen, also die Software.

Jetzt in eurem Fall in Python geschrieben, die nimmt die Daten entgegen.

So.

Jetzt nimmt es die Daten so, wie sie sind und schmeißt sie in die Datenbank.

Die Datenbank hat, äh, kann ich nicht einfügen, falscher Datentyp oder was auch immer.

Gibt dann, erstmal habt ihr eine Verbindung aufgemacht, die sind bei Postgres relativ teuer.

Da rein.

Die gibt dann zurück, kann ich nicht.

Ihr kriegt den Fehler, behandelt den Fehler wieder in Python.

Das ist doch dann sinnvoller, bei sowas wie Postszeitzeit, das gleich in Python zu prüfen.

Oder auch beim Geschlecht oder sowas.

Das Problem ist halt dann die Frage, ob ich jetzt wirklich alle Ausnahmen irgendwie abfangen kann, die sich irgendwie ausdenken kann.

Oder das halt alles runterbreche.

Oder ob ich sage, ich mache da einfach ein Textfeld draußen, das ist mir egal und dann ist halt dann die Identlichkeit.

Aber was ich bei Postseitzeil machen würde, ist, die gibt es ja als CSV, die würde ich ja einmal importieren und dann würde ich mir die Assist, dann kann er die auswählen.

Also die skripte, ja, okay, Toy Sweet, ja gut, aber.

Ja.

Ja, aber wenn

das Produkt ist, ist halt schon.

Oder die Stadt anfangen einzugeben und dann zeichnet der automatisch das.

Na gut, aber da muss ich ja das Formular schon in der Hand haben quasi.

Ja, aber da gibt es halt unterschiedliche Sichten.

Also ich meine, aber ich finde das Problem deswegen schön, weil das halt vielleicht klar macht, dass das alles nicht so ganz einfach ist.

Also ich meine, aus einer Datenbanksicht kann ich mir vielleicht eine ideale, ich habe auch, das hat wahrscheinlich jeder schon ein paar Mal gemacht, aber irgendwie so versucht, normalisiert Adressen zu speichern.

Und dann, wenn man das aber dann benutzt, dann stellt man fest, so, uh, das gibt aber ganz viele Fälle, die passen dann halt nicht.

Mannheit.

Mannheit.

Irgendwelche halligen Dinge, die halt irgendwie nicht so richtig da reinpassen wollen.

Also dann, wenn man dann sich mit Leuten unterteilt, die dann aus dem Web-Dings da drauf gucken, die sagen dann eher so, ja, okay, du kannst das ja vielleicht in der Datenbank so speichern, aber wenn du es zum Beispiel dann hinterher irgendwie Leuten anzeigen oder ausdrucken oder sonst irgendwie, dann nimm halt immer irgendwas, was reiner Text ist, weil alles andere geht eh nicht.

Alles andere kannst du eh nicht machen, weil es funktioniert hinten und weiter.

Also was ich tatsächlich mache, ist, ich mache einfach mal nur Adresse 1 bis 6.

Sechs Felder.

Da können die reinschreiben, was sie wollen.

Also so.

Du kannst es ja dann irgendwie prüfen.

Also, ich weiß nicht, wie du es prüfst.

Irgendwie Rack-Exsen, wenn es nicht matcht, dann irgendwie Error, oder?

Also du kannst die Ländercodes kannst du natürlich, ich würde auch sowas wie Postzahlen nochmal extra vielleicht, die kannst du ja importieren.

Ja.

Für Deutschland ja.

Hast du natürlich, wenn du international bist, dann auch wieder.

Aber ist ja mal so Straßen.

Mannheim hat ja die Quadrate T633, habe ich mal drin gewohnt, glaube ich, und so.

Aber das geht halt auch nur dann, wenn ich halt den Input wirklich kontrollieren kann.

Wenn ich halt irgendwas bekomme und das muss halt dann da ins Postleitzahlenfeld rein, dann ist das natürlich schwierig.

Die Frage ist,

wofür brauchst du.

Wofür willst du das unbedingt in das Postleitzahlen?

Warum willst du da unbedingt irgendwas reintun, was keine Postleitzahl ist?

Weil ich die Adresse anlegen muss, um eine Bestellung anlegen zu machen.

Ja, aber dann

tu doch die Adresse in ein Textfeld.

Ja, genau.

Ja, ja.

Dann meine ich ja.

Und dann kannst du ja versuchen, eine Postleitzahl zu extrahieren oder so.

Ja, oder die Postleitzahl kommt direkt ins Textfeld.

Die Frage ist ja, wofür brauchst du diese Adresse?

Genau.

Ja, nein, also halt nur schwierige wird, hinterher ist halt Filtern von Adressen zu sein.

Wenn du ein Verkäufer bist, der etwas online verkauft und du brauchst jetzt die Lieferadresse, um das dem Kunden zu liefern, da hat der Kunde ja schon ein gewisses Interesse dran, das richtig zu verändern.

Dann liegt halt das Textfeld, dann kommt das halt auch an.

Aber wenn ich jetzt dann hinter an der Analyse hingehen will, in welchem Postarzahlengebiet habe ich denn jetzt wie viel geliefert beispielsweise, dann ist halt dann das Problem, dass die Textwelte halt nicht mehr halt.

Ja, aber dann ist halt die Frage, wie wichtig ist es, bis auf die letzte Adresse stimmt und dann.

Genau, da muss ich hier dann halt ein Filter überlegen, wie ich das dann wieder rausgehe.

Dann ist auch die Frage, ob du diese Analyse überhaupt fahren darfst oder ob das gegen die Datenschutzrichten für dich ist.

Ja gut, aber das ist ja ein anderes Problem.

Im Zweifel hat man ja berechtigte Interessen und dafür eine jeweilige Datenschutzvereinbarung.

Hatte bei Business to Business-Kunden am meisten schon.

Ja, das ja.

Aber ich habe die hier gleich aufgegessen.

Das ist halt lecker.

Nein, aber das ist so dieses, ähm, nee, aber tatsächlich, ich habe das auch jetzt schon mehr erfahren.

Ich habe dann mal angeguckt, was passt denn auf dem Briefkopf?

Ich glaube, du hast sechs Zeilen, du hast fünf.

Also ein normaler Briefkopf hat immer fünf oder da habe ich immer, mir heißt die Adresse 1, Adresse 2 oder ADR 1, 2, 3, 4, 5, 6, weil mir ist es doch auch völlig egal, ob der Name der Kunde jetzt ganz oben steht oder in der zweiten Zeile.

Der Kunde wird ja wissen, wie seine Rechnung ist, beziehungsweise wie seine Adresse ist.

Und wenn der was geliefert haben will, hat der auch ein entsprechend großes Interesse, dass das ankommt, dass er seine Adresse schon richtig da eintippt.

Und dann schickst du ihm ja auch nochmal eine E-Mail, bevor du das lieferst und so weiter und so fort.

Bei Rechnungsadressen.

Ja, ich glaube,

das ist wurscht.

Also da ist das ja, die schickst du ja auch selten noch mit der Post.

Ich glaube, das Normalisierungsthema würde ich dann damit auch abschließen wohl.

Und ich würde gerne noch zu was anderem überkommen.

Und zwar könnt ihr euch jetzt aussuchen, ob ihr erst Transaktionen sprechen wollt oder Verbindung oder über No SQL wie es SQL.

Am Ende wollte ich mir nochmal Maria gegen Postgres.

Das finde ich auch schon schon.

Was wolltest du zu Transaktionen wissen?

Vielleicht erstmal, was ist das überhaupt?

Also ich müsste ja davon ausgehen.

Also eine Transaktion ist, der Dominik möchte dem Jochen 100 Euro überweisen.

Jetzt zieht die Bank, stell dir vor, du bist eine Bank.

Jetzt zieht die Bank die 100 Euro von Dominiks Konto ab und die Datenbank bricht zusammen.

Oder das System bricht zusammen.

Ja, das ist halt beim Jochen nichts angekommen, aber beim Dominik sind die 100 Euro auch weg.

Das wäre nicht gut.

Das ist in einem schwarzen Loch versunken.

So.

Also macht man das Ganze in einer sogenannten Transaktion.

Das heißt, beim Dominik werden die 100 Euro abgezogen und beim Jochen draufgepackt und erst wenn beides passiert ist, ist der Prozess abgeschlossen.

Das macht man mit dem Commit.

So heißt der Befehl.

Wenn jetzt zwischendurch das Datenbanksystem abfällt.

Sagen wir mal, die 100 Euro werden abgezogen und das System bricht zusammen.

Dann ist kein Commit passiert, sondern dann wird das Ganze zurückgerollt und dann hat der Dominik dann, sobald das System wieder da ist, die 100 Euro noch auf dem Konto und es ist einfach gar nichts passiert.

Okay, also tatsächlich eine Isolation von mehreren Arbeitsschritten.

Ja, nicht nur von mehreren, eigentlich war es früher so, das ist auch heute noch so, das wird heute so automatisiert, dass es keiner mehr weiß.

Sobald du irgendwas auf eine Datenbank schreibst, jedes schreibende Zugriff, also jeder, nein, eine Transaktion ist eigentlich jeder Befehl, aber jede schreibende Transaktion, das heißt, du machst ein Insert oder ein Update.

Wenn du das mal so früher in C gemacht hast, musstest du immer ein Commit hinten dran werfen.

Warum jetzt unbedingt den C?

Die Programmiersprache war eigentlich egal.

Aber du musstest immer einen Commit hinten dran werfen.

Also du musstest immer erstmal Insert sagen und dann darunter Commit.

Danach.

Mittlerweile machen die Datenbanksysteme alle Autocommit.

Das heißt, wenn du einen Insert-Befehl abfeuerst, dann wird er automatisch committed.

Aber das Commit ist natürlich intern immer noch da.

Aber es wird halt automatisch da hinten dran gefeuert, dass du das nicht mehr machen musst, dass es da immer noch ein Commit-1 hinterher ist.

Das kann man auch ausstellen.

Und das kannst du ausfallen, dafür gibt es den SQL-Befehl.

Im Standard-SQL heißt das Start-Transaction, damit stellst du das Autocommit aus.

Dann machst du deine ganzen schreiben und Transaktionen und sagst am Ende Commit.

Das wäre jetzt das mit dem Kontoüberweis.

Das würde man zum Beispiel machen in der Business-Logik von so einer Applikation, wo er inzwischendurch noch andere Dinge abfragen musst, wo man Verbindungen aufbauen muss, wo man nicht weiß, ob die klappen oder so, ja.

Ja, also bei allem, wo du mehrere Schritte hast und die halt entweder alle funktionieren sollen oder keine Ahnung.

Ja, genau.

Also das mit der Bank ist immer so ein, das macht die Banken, die funktionieren natürlich noch viel komplexer, aber das ist immer so ein schönes Beispiel, weil das ist so schön anschaulich.

Und genau, und Postgres und Maria.db haben aber eine Abkürzung für Start Transaction, das ist Beginn, also da kann man auch Beginn sagen, statt Start Transaction, das ist weniger Tipparbeit.

Und das ist halt so ein schönes Beispiel, aber man hat tatsächlich immer mal wieder solche Fälle in Anwendungen, wo du das brauchst, tatsächlich, dass du das in einem, ja.

Oder, ne, das ist wirklich so, entweder alles oder nichts.

Ist das im Grunde.

Also man hat erstmal so ein Netter und dann muss man die einzelnen Transaktionen dann committen und dann gucken.

Sehr schön, auch wenn du jetzt mal ganz große Sachen.

Ich sag mal, ich hatte vorhin schon ein paar Mal gesagt, du willst jetzt aus dem CSV die ganzen Postzeilen Deutschlands importieren.

Ja, aus dem CSV, okay, das ist eh nur eine Transaktion, aber du würdest das mit dem Insort-Statement machen.

Da möchtest du auch entweder alle drin haben oder keine.

Du willst nicht irgendwo, dass der dir nach der Hälfte irgendwie, dann hast die halben Postatzeilen drin und die andere Hälfte nicht.

Du würdest entweder alles eins, würdest du auch mit einer Transaktion machen, wie gesagt, wenn du das CSV hochlädst, ist es nur eine, aber könntest du es auch anders lösen.

Das war jetzt zum Beispiel, was mir einfällt.

Also es gibt da aber durchaus ganz viele, kriegt er wahrscheinlich jetzt ganz viele Zuschriften, was da die Leute als Beispiel schon haben für Transaktionen.

Aber das ist so, dass Transaktionen und das wird mitgelockt tatsächlich.

Das Transaktionslog ist ja das Wichtigste überhaupt bei Postgres oder bei Datenbanken.

Und das wird halt mitgelockt, damit du dann, wenn deine Datenbank abstürzt, hast du immer noch das Transaktionslogs und aus dem Bestand, den du auf der Festplatte in deinem Datenverzeichnis hast und den Transaktionslogs kann die Datenbank wieder hergestellt werden.

Die Backups ja wichtig.

Naja, aber die Datenbank muss es halt schon irgendwann mal geschrieben haben auf die Platte.

Die Transaktionslogg schreibt halt immer auf die Platte, das ist das Wichtige daran.

Es sei denn, man hat, da muss man immer aufpassen.

Aber man kann es auch abschalten, macht Tests unter Umständen schon darauf.

Man kann das abschalten, ja.

Das kann man machen.

Ganz viel fieser ist, aber dass Festplatten nicht unbedingt permanent speichern.

Dass auch Festplatten mittlerweile irgendwelche Caches haben und wenn dann wirklich mal so richtig heftig was ausfällt, ist in Deutschland seltener, ist in Amerika, mit Stromausfällen haben wir jetzt nicht ganz so viel hier zu tun.

In Amerika fällt ja ganz häufig der Strom aus und so weiter.

Dass dann das nur in dem Cache der Festplatte war und noch gar nicht richtig auf der Festplatte und dann weg ist.

Da wird dann immer geraten, man soll den Plattencache ausstellen und solche Geschichten, damit das dann.

Ah, okay, ja gut, ich weiß es nicht genau.

Ich glaube, man kann.

Auch bei VMs, dann sagt die VM, es ist fest auf der Platte, es ist aber erst im Cache des Hauses oder so.

Das ist auch was, da habe ich bei VMs dann keinen Einfluss drauf.

Also bei den Datenbanken, so Hardware-Datenbanken, die ich mal so irgendwie in Rex gesehen habe, die hatten meistens dann halt so Red Controller mit Batterien drauf.

Ja, Battery Wax.

Ansonsten, ich glaube, also Postgres verwendet irgendwie F-Sync und F-Sync kann man auch irgendwie sagen, so sag mir, sag, werd erst fertig, wenn du es wirklich, wirklich auf der Platte geschrieben hast.

Das ist das,

das macht es auch langsamer, aber ja.

Nein, F-Sync ist das, was wir immer den OpenStreetMap sagen, stell das aus, wenn sie wieder ganz NRW oder die halbe Welt hochladen wollen, weil das geht schnell.

Und da kannst du auch mal sagen, entweder du hast alles oder gar nichts, du willst ja die ganze Welt hoch.

F-Sync sollte man nie abschalten.

Es gibt so ein chronus Commit bei PostgresQL und bei MariaDB heißt das Ganze.

Ein Kollege von mir sagte mal, es ist die längste Variable, die es gibt.

Es gibt die Variable mit selber, also die heißt nur anders.

Das kannst du ausstellen, dann würde es schon das Agg, das OK, zurückgeben, wenn es im Cache, wenn die Transaktion im Cache liegt und nicht auf der Platte.

Ansonsten kriegst du immer erst das, wenn du ein Statement abfeuerst, kriegst du erst das Agg, das Acknowledgement oder das OK zurück.

Wenn wirklich das von der Transaktions, wenn das System sagt, ja, das Transaktionslog, also dieser Schnipsel, den du da geendet hast, der ist jetzt wirklich auf der Festplatte, im Transaktionslog.

Und du kannst halt das Transaktionslock haben nochmal ein Cache da drüber und du kannst halt auch schon sagen, okay, gib mir das schon zurück, wenn das in dem Cache angekommen ist.

Da verlierst du bei PostgreSQL maximal 600 Millisekunden an Transaktionen.

Also deine letzten 600 Millisekunden an Transaktionen kannst du verlieren.

Ist bei MariaDB nicht anders.

InnoDB Transaction Commit irgendwie so ähnlich.

Ist eine ganz lange Variable bei MariaDB, ich weiß immer nicht, wie sie hieß, wie sie heißt.

Dann gab mir mein Kollege, ein ehemaliger Kollege, meinen Tipp, sagt er, ich weiß auch nicht, wie sie heißt, aber es ist die längste Variable, die es gibt.

Und ich habe dann wirklich, Maria DB hat wahnsinnig viele Server Variablen.

Es war wirklich die längste, aber ich glaube, es gibt mittlerweile eine längere.

Aber sie ist relativ sprechend auch.

Also Flush Transaction Commit irgendwie so ähnlich heißt sie.

Genau.

Und das ist das, aber F-Swing sollte man eigentlich nicht abstellen.

Wie gesagt, die OpenStreetMapler, wenn die dann wirklich anfangen und wir laden jetzt mal auf dem frischen Server irgendwie die halbe Welt, dann ist F-Sync abstellen, dann sind die wesentlich schneller fertig.

Und da kann man auch sagen, okay, wenn jetzt nach zwei Tagen die halbe Welt nicht da ist, dann fangt man von vorne an.

Wenn dann wirklich mal der Server abgeraucht ist.

Nur da sollte man wirklich wissen, was man tut.

Ja, ja.

Ja, genau, aber ich glaube, also Isolation und so, das gibt es ja auch noch, aber es gibt halt eigentlich, Transaktionen ist ja nicht das einzige Ding.

Also eigentlich will man ja diese Asset-Bedingungen halt sozusagen gewährleistet hat.

Also je nachdem, manche Sachen reicht auch eventuell.

Also Datenbanken sollten Asset-konform sein, das heißt Atomar, das wäre mit der Normalisierung zu lösen.

Konsistent, auch das macht man über die Normalisierung.

Die Isolation, die macht man über Isolationslevel, das wird aber automatisch gemacht und wir haben den Isolationsmittel-Committed oder Repeater Beweed ist sowieso Standard.

Da muss man eigentlich nicht nochmal dran.

Es sei denn, man ist irgendwo im tiefen und diversitären Bereich und will das auf Serialiser bestellen.

Da kann ich aber auch sagen, die meisten Bugs haben alle Datenbanksysteme, haben Riesenprobleme mit diesem Isolationsmittel.

Können wir nochmal drüber machen, was das bedeutet.

Und dann haben wir noch die Duability oder in Deutsch heißt das so schön dauerhaft.

Und das ist heute ein Riesenproblem, weil Datenbanken sollten natürlich dauerhaft speichern.

Und das hatte ich vorhin schon angedeutet.

Das ist so eine schöne Theorie, warte, bis es auf der Festplatte ist.

Aber ganz, ganz viele Datenbanken laufen heute auf virtuellen Maschinen.

Und Festplatte heißt dann die Festplatte vom Host und viele virtuelle Maschinen sagen, ja, das ist auf der Festplatte, obwohl es erst im Rahmen des Hostes liegt und noch gar nicht wirklich auf der Festplatte.

Und da habe ich zumindest als Datenbanksystem erstmal keinen Einfluss drauf.

Das ist dann eine Administratorsache, das dauerhaft hinzukriegen.

Und jetzt guckst du mich fragend an, ich weiß auch nicht wie.

Also ich weiß nur, dass wir ganz häufig, wenn ich ganz komische Artefakte habe und in den Kunden frage, ist das eine virtuelle Maschine?

Also ich hatte auch schon Kunden, die dann Nein gesagt haben, dreimal und am Ende kam raus, das war doch einer.

Weil du kannst auch diese Übergabe, je nach virtueller Maschine, also je nach System, da gibt es ja KVM und was auch immer, ne?

Kannst du das nicht wirklich monitoren oder was da der Host eigentlich noch macht, also diese Übergabe virtuelle Maschine Host.

Dann verschwinden die Daten, die virtuelle Maschine sagt, ich bin fertig, aber es ist vom Host noch gar nicht da abgelegt, wo es sein soll.

Oder du hast nicht genug RAM gekriegt vom Host oder was auch immer.

Also es gibt da ganz lustige Artefakte mit den virtuellen Maschinen.

Womb, kabum.

Ja, nur das ist halt so, dass mit der Dauerhaftigkeit.

Isolation heißt, ähm, wenn.

Ja, also wenn, ob man jetzt zum Beispiel begonnene, die Daten, die geänderten Daten begonnene, Transaktionen schon sehen kann in einer anderen oder halt erst, wenn die Transaktion durch ist, zum Beispiel, oder so solche Sachen halt.

So wer wann welche Sachen sehen kann.

Fällt mir ein nettes Beispiel zu ein, Jochens Frau möchte Jochen einkaufen schicken.

Und Jochens Frau hat da so ein paar Sachen irgendwie an die Wand geschrieben, die eingekauft werden sollen.

Hat aber noch fünf weitere Sachen im Kopf, die sie da drauf schreiben will.

Jochen geht schon einkaufen

hat die Liste gemacht.

Nein, Jochen hat jetzt schon mal ein Foto gemacht von der Liste und ist einkaufen gegangen.

Und die Frau schreibt dann erst, ne, und erst danach schreibt die Frau die Sachen auf die Liste.

Das heißt, Jochen hat sich schon noch nicht gekriegt.

Also es ist im Grunde, also jeder, der was ändert, ändert das erstmal für sich, ohne dass es ein anderer sieht.

Und der andere sieht das erst, wenn auch wirklich das Commit gekommen ist.

Dann sieht der andere erst erst, das ist das Read committed.

Also ich kann erst das vom anderen lesen, wenn er das auch wirklich committed hat.

Es gibt in der Theorie noch Dirty Read und Phantom Read und so weiter.

Das wären Sachen, dass der andere das schon lesen kann, bevor ich das committed habe.

Das hat Postgres gar nicht implementiert.

Das ist sehr einfach, das haben wir gar nicht implementiert.

Ich hatte letztens eine Migration, die hatten ganz viel Read, dieses Dirty Read benutzt.

Und dann habe ich dann die Entwickler gefragt, warum braucht ihr das?

Dann mussten die erstmal ganz tief forschen.

Ja, weil das hat mal ein Kollege, der längst in Rente ist, gesagt, dann ist das irgendwie schneller oder so und dann mussten die noch länger forschen und dann haben sie festgestellt, eigentlich brauchen wir es gar nicht, das können wir auch komplett anders machen.

Nur weil Postgres das ja einfach nicht kann.

Also wir fangen erst mit Read Committed an, das alles darunter geht nicht.

Bei MariaDB geht es, glaube ich, so ein bisschen, habe ich aber auch noch nie wirklich eingestellt.

Und das Repeatable Read ist, wenn jetzt einer anfängt, ein Select zu machen und er braucht jetzt den Wert aus Spalte 5 und der Wert, sagen wir es 7.

Und der Select läuft länger und er braucht diesen Wert mehrfach in diesem Select Query.

Also er greift mehrfach auf diese Spalte 5 drauf zu, um den Wert 7 nochmal, weil er da irgendwie Berechnungen macht.

So, und währenddessen ändert ein anderer den Wert auf 9.

Ist natürlich doof, weil dann hat das Query, das Select Query mal 7 mal 9, das will man nicht.

Und dann kriegt halt Repeatable Read, heißt, wenn er das einmal gekriegt hat, kriegt er dieses Ergebnis auch bis zum Ende.

Das heißt, du bekommst dann immer die 7.

Die 9 wird ja erst, wenn du das Selector nochmal ausführen würdest, würde es komplett mit 9 machen.

Das ist Repeatable Read.

Das kann PostgreSQL.

Auch wenn da irgendwie, ich glaube, wir nennen das nur Read Committed, weil es kann ja mal passieren, dass auf dem Mars ein Vulkan ausbricht und den Islandkreis gerade schneit und der Jupiter mit dem Saturn auf einer Linie steht, da gibt es irgendeine Ausnahme.

Keine Ahnung.

Aber Maria HDW macht es auch.

Also das ist eigentlich das auch, was standardmäßig heute passiert.

Und dann gibt es noch den Ziele.

Da kriegst du immer dasselbe Ergebnis, solange wie die Session offen ist.

Okay.

Und das ist natürlich sehr, sehr schwierig.

Also wenn du da drei Tage eine Session offen hast und das wird dann immer noch das Ergebnis von vor drei Tagen.

Das ist 30 Mal geändert worden.

Das ist sehr, sehr schwierig zu implementieren.

Und deswegen, wenn man mal so in die Buglisten guckt für die Datenbanksysteme, egal ob ich einen Oracle nehme oder eins der IBMs oder Maria.b oder PostgreSQL, es gibt da Bugs im Bereich Serializable.

Also wenn man da so SQL-Bugs ist, es ist ganz häufig, dass es nur den Serializable betrifft.

Weil das auch unwahrscheinlich schwierig ist zu implementieren.

Ich habe immer noch nicht rausgefallen in all diesen 20 Jahren, wann überhaupt das Serializable mal sinnvoll ist und wann er eingesetzt wird.

Meine Information ist im universitären Bereich, aber auch da ist er mir persönlich noch nicht begegnet.

Also, keine Ahnung.

Das macht man nicht so ohne weiteres.

Aber was halt heutzutage, wo man immer ein bisschen dran denken muss, ist an dieses Dauerhaft.

Als Admin muss man da so ein bisschen dran denken, dass man Datenbanken auch dauerhaft hat.

Da hat das mit der Session vielleicht was mit Verbindungen zu tun?

Eine Verbindung in eine Session ist ein und dasselbe.

Okay.

Da können wir jetzt vielleicht direkt drauf einsteigen, weil das nur noch ein Punkt auf der Liste war.

Also, wenn ich natürlich, das ist eine Client-Server-Anwendung, du hast halt den Datenbank-Server oder auch Dienst oder auch Daemon genannt und du hast deinen Client.

Der Client kann alles Mögliche sein.

Das kann die Software sein.

Das ist in der Regel ein Stück Software, was auf die Datenbank zugreift.

So kann ich das am einfachsten sagen.

Am einfachsten erklärt es immer bei dem Web-Service gibt es auch Client-Server.

Du hast einen Web-Server irgendwo stehen im Rechenzentrum und es ist die Browser, die drauf zugreifen und das sind die Clients.

Das heißt bei Datenbanken genauso, nur dass da die Clients halt in der Regel Software sind.

Und ja, diese Software macht dann eine Verbindung zur Datenbank auf.

Und die macht für und schickt dann das Query, was sie anfragen will, die Datenbank Anfrage, das kann jetzt das sein, was sie schreiben will oder was sie lesen will, schickt sie zu der Datenbank, die Datenbank führt das Ganze aus und schickt das dann über diese Verbindung zurück.

Man kann pro Verbindung zeitgleich pro Verbindung und zeitgleich immer nur ein Query abschießen.

Das ist auch bei allen Datenbanksystemen so.

Also es geht nicht, dass du in derselben Verbindung zeitgleich zwei Querys abschießen.

Das geht nicht ab, Feuerst.

Also du brauchst halt, wenn für jedes zeitgleiche Query, was du abschicken willst, brauchst du eine extra Verbindung.

Ja.

Also wenn es wirklich richtig zeitgleich ist.

Nacheinander kannst du natürlich, aber pro Verbindung kannst du.

Das heißt, du musst entweder mal warten oder tatsächlich mehrere Verbindungen auf.

Ja, das wird jetzt auch mit Async und so sehr interessanter noch, ja.

Ja, du musst halt mehrere Verbindungen aufmachen, das ist aber auch nicht tragisch.

Da ist halt die Frage, wenn die was auf was Gleiches zugreifen, auf die gleiche Zeile oder sowas.

Nee, damit hat das nichts zu tun.

Damit hat das nichts zu tun.

Damit hat es, also eine einzelne Verbindung hat damit nichts zu tun.

Du kannst natürlich, wenn du zwei Verbindungen hast und die greifen auf dieselbe Zeile zu, da muss der eine auf den anderen warten.

Aber von der Datenbankseite her dann.

Von der Datenbankseite, das macht die Datenbank.

Aber du musst halt immer bedenken, du hast eine Verbindung.

Und bei Postgres, bei Postgres ist eine Verbindung ein echter Prozess.

Und deswegen sind die Verbindungen so teuer.

Bei MariaDB ist es ein Thread.

Da hast du irgendwann Probleme bei, ja, wenn de TCP-Ports ausgehen.

Weil, wenn du da, das hatte ich schon ein paar Mal, dass ich Webserver hatte, dass die dann mit 5, 6, 7 oder mit 30 Web-Servern auf eine Datenbank und hast irgendwann keine TCP-Ports mehr, dann hast du, fängst du mal an und das macht, da gibt es dann ein Pooling von InnoDB für, dass du da noch mit 100.000 Verbindungen zeitgleich und so weiter auch noch spielen kannst.

Bei Postgres und bei denen, die prozessbasiert sind, also fast alle anderen großen, bist du da viel früher dran, dass du da Probleme kriegst, weil jede Verbindung ist ein echter Prozess.

So, und jeder Prozess braucht vom Betriebssystem her erstmal einen Chor, einen Kern, einen Chor.

Ich kann pro Core zeitgleich nur einen Prozess abbilden.

Das heißt, wenn ich acht Verbindungen auf habe und ich habe acht Cores, dann läuft auf jedem Core eine Datenbankverbindung.

Zeitgleich.

Wenn ich da mehr Verbindungen zeitgleich auf habe, sagen wir mal, ich habe jetzt vier pro Core auf, dann gibt es einen Betriebssystem Scheduler, der das scheduled.

Und ja, dann gab es mal vom Postgres diese nette Empfehlung von meinem lieben Kollegen aus den USA.

Ja, so vier Verbindungen pro Core, zu einer Zeit, wo Cores auch noch nicht so gut verbreitet waren.

Also generell, auch bei MySQL ist das übrigens nicht anders.

Datenbanken sind immer sehr, sehr chorlastig.

Je mehr Cores, umso besser, gerade bei Webanwendungen und so weiter.

Du kannst da nie genug vonhaben.

Und du musst dir halt überlegen, wie viele Verbindungen habe ich zeitgleich.

Und weil das echte Prozesse sind, ist da auch irgendwo mal eine Grenze.

Man sagt so, vom Bauch her irgendwie so 200, 400.

Das ist, je nachdem, wen du fragst, ist das ein bisschen anders.

Aber es gibt ein Connection-Pooling.

Das heißt, du packst zwischen deiner Datenbank und deiner Anwendung einen Pooler.

Ist sehr lustig.

Ich habe mal in meiner Studentenzeit im letzten Jahrhundert, Anfang dieses Jahrhunderts, hatte ich einen Job bei einer großen deutschen namhaften Firma.

Und damals hatte der Datenbankhersteller die Idee, wir verkaufen mal Datenbanklizenzen pro Verbindung.

Richtig teuer.

Und die Firma hatte dann fünf Verbindungen zu dieser Datenbank gekauft.

Und ich durfte dann einen Pooler schreiben, der dann dafür sorgte, dass immer nur fünf Verbindungen zu dieser Datenbank kamen und alle anderen wurden dann gescheduled, ähnlich wie das Betriebssystem das Scheduled.

Da gibt es dann häufig wird der Round-Robbins-Scheduler genommen, der das dann poolt.

Und sowas gibt es halt auch für die Datenbanksysteme.

Der von Postgres heißt PG Bouncer, den wir immer empfehlen, wenn es keinen anderen gibt.

Den setzt du meistens in die Nähe der Datenbank.

Auch das ist eine Sache, die kannst du bis zum Umfallen diskutieren, setze ich den Pooler in die Nähe der Datenbank oder setze ich den in die Nähe der Anwendung.

Wenn ich eine Java-Anwendung habe, irgendwas mit Tomcat und weiß der Kuckuck was, die bringen meistens einen Pooler schon mit, da brauche ich keinen zweiten.

Das ist auch sowas, das sehe ich immer.

Ich sehe manchmal Datenbanken, die haben dann drei Pooler, wo ich mich frage, warum einer reicht.

Wie ist das bei Python?

Weiß ich jetzt nicht.

Nee, da ist es also zum Beispiel Django macht das jetzt auf der Nick Up 4.1, kommt jetzt irgendwann im Sommer, da gibt es einen internen Pool sozusagen, also für die, äh, für, aber normalerweise kannst du die Anzahl der Verbindungen, die jetzt deinen Applikationsserver sozusagen zur Datenbank macht, kannst du normalerweise einstellen.

Aber das ist jetzt halt schwierig geworden mit Async, weil wenn du jetzt sagen wir mal so fünf Querys machst und die können alle gleichzeitig laufen und ab Django 4.1 hast du halt auch schon zumindest ein Async-Interface für deinen ORM.

Also der ORM ist noch nicht async-fähig, aber es gibt zumindest das Interface.

Dann ist halt natürlich der, dann könnte sozusagen dann der ORM fünf Verbindungen aufmachen, die alle gleichzeitig rausschicken.

Weil geht halt nicht auf einer Verbindung, du sollst fünf Verbindungen aufmachen.

So, wenn du jetzt aber eingestellt hast in deiner Datenbank, äh, in deiner Django-Config, soll aber nur zwei Verbindungen zur Datenbank aufmachen, dann ist das natürlich ein Problem.

Also das muss man dann halt irgendwie handeln und dafür gibt es halt dann eine Pool-Implementierung direkt in Django, jetzt ab der nächsten Version.

Aber genau.

Ja.

Also wie gesagt, das kann ein bisschen auf deiner Hardware drunter an.

Ich sehe, du findest da so etwa 200, 400 Verbindungen.

Muss auch mal gucken, zeitgleich.

Das ist auch sowas, wenn man das mal monitort, das ist bei MariaDB einfach zu monitoren als bei Postgres, da habe ich da 10.000 Verbindungen.

Dann gucke ich, habe ich zeitgleich vielleicht maximal 64 gehabt.

Exakt zeitgleich.

Also das muss man ja auch gucken, wie viel sind das denn wirklich exakt zeitgleich.

Das ist so das mit den Verbindungen.

Aber die

so schnell halt so wieder zu sind, ne?

Ja, also ich meine, das ist halt, würde ich sagen, das ist einer der Hauptvorteile von früher auf jeden Fall von MySQL, dass man da nichts machen musste.

Dass halt so quasi jedes Statement, das man abgefordert hat von VHP aus, hat halt einfach eine eine oder Verbindung aufgemacht, dann nach dem Statement war sie wieder zu.

Nein, nichts machen.

Also ich hatte jetzt tatsächlich mal während der Pandemie einen Kunden, der durfte ich dann mit Servern spielen mit 128 Kores.

Das war schon sehr lustig.

Aber die Verbindungen waren dann auch, da hatte ich auch zeitgleich mehr, aber da hatte ich dann so irgendwie in die 200.000 Verbindungen und noch mehr.

Und da fängst du dann auch bei MariaDB an zu poolen und dann wird es lustig.

Das macht's Spaß.

Weil dir dann auch irgendwie, wie gesagt, du da hampelst ja, rechnest du dann auf einmal, wie viele Ports habe ich denn überhaupt.

Und ja, und liebe Webserver, könnt ihr da vielleicht auch nochmal was vorschalten oder so?

Aber das ist dann schon Spaß.

Ja gut, man kommt da wahrscheinlich auch irgendwann ein, aber so viel Feld und Wiesen LabStack war das halt, da ging das eigentlich immer.

Das ist auch das, was viele halt falsch machen, wenn sie von der Maria die MySQL-Massine zu Postgres kommen, dass sie dann die Verbindung so wahnsinnig hochsetzen und dann macht das Betriebssystem auf einmal die Gretsche.

Das ist auch so eine Sache.

Genau.

Naja, also das war irgendwie, das war jedenfalls früher war das immer so ein, fand ich, so Hauptsellingpoint für MySQL, dass man sagen kann, okay, das kostet vielleicht eine Latenz 30 Prozent oder so, aber dafür muss man sich keine Gedanken um diese ganzen Sachen machen.

Und die Infrastruktur ist einfacher und so und ja.

Lizenz hatten wir noch gar nicht drüber geredet.

Also wir hatten angefangen, also Postgres ist halt BSD und BSD ist sehr, sehr einfach zu handeln, deswegen hat man das auch viel in Maschinen, auch beim Betriebssystem ist das viel BSD.

MariaDB ist GPL und die haben dann noch die erstmal muss man bei der GPL ja mal gucken, Light GPL und welche Version und Verträge sind ein bisschen länger und man muss dann gucken, MariaDB hat so dieses, ich denke mal, das haben sie immer noch, du kannst es nutzen für deine eigenen Zwecke, aber wenn du Software hast, die du verkaufst, dann musst du nämlich eine Lizenz bei MariaDB kaufen, was ja auch

irgendwo eine faire Geschichte ist.

Wenn du das dann nutzt in deiner Software, die du verkaufst, dann musst du Lizenzen kaufen.

Genau.

Und dann gibt es bei Postgres noch, es gibt dann immer, das nennen wir immer das Contrib-Verzeichnis, es gibt dann auch so Tools.

Bei einigen dieser Tools fragt man sich, warum zur Hölle ist das nicht im Hauptpaket mit drin.

Das hat man ganz auf.

Also es gibt da zwei Gründe.

Das eine ist, weil das Tool so groß ist.

Früher musste der Code ja noch auf eine Diskette passen, ganz lange.

Nein, nein.

Eine Diskette hatte 3,5.

5,5.

Das sind die großen.

Nein, wie viel, wie viel, wie viel,

wie viel MB, 1,44 MB.

1,44 Megabyte, genau.

Ja, so.

Und ihr wisst noch, was eine Diskette ist.

Ja, ja, ich kenne das nicht.

Die Meeks sind 5,25 Zoll angefangen.

Ich bin noch mit Datasette angefangen.

Ah, Dataset, ja.

Aber, ja.

Und dann gibt es dann so ganz große Projekte wie das PostGIS mit den ganzen Geodaten oder der JDBC für Java.

Das sind so große Projekte, wo man gesagt hat, okay, die macht man einfach einzeln, weil die braucht nicht jeder.

Die kann man nachladen.

Erstmal das, das ist das eine.

Das andere ist, es gibt auch kleine Projekte, wo man sich vorum zur Hölle ist das nicht mit drin.

In 99% oder in 98% der Fälle, können auch 100 sein.

Nein, also in 99, sage ich mal, liegt das an der Lizenz, weil diese Tools irgendwas nutzen, was GPL mitbringt.

Was nicht mehr mit der BSD hier Lizenz kompatibel ist und wo man dann ansonsten das, also die irgendwas nutzen, was dann aus der GPL-Welt kommt.

Und das dann.

Also um

da nochmal vielleicht zusammenzufassen, GPL tendiert dazu, dass die Lizenzen halt nicht kommerziell frei nutzbar sind für alle Zwecke, sondern nur privat.

Und BSD hat halt für alle Zwecke auch für kommerzielle komplett freie Verwendung.

Achso, hast du schön gesagt, deswegen findest du auch immer Postgres in deinem Auto?

Nein.

Was ist das der Unterschied zwischen BSD und MIT-Lizenz?

Gibt es da überhaupt einen?

Ist das quasi dasselbe?

Nee, MIT nicht.

BSD ist Barclay.

Und MIT-Lizenz?

Das ist eine andere, das weiß ich nicht.

East Coast versus West Coast, ich weiß nicht.

Ich weiß auch nicht.

Aber die sind tatsächlich relativ ähnlich.

Also die sind sehr liberal.

Genau wie Apache auch, ist auch sehr liberal.

Ja, Apache ist auch, genau, ne, das ist so, dass.

Da gibt es auch Patentgeschichten, aber es ist auch.

Offiziell heißt die von Postgres auch Postgres-Lizenz, das ist aber die BSD-Lizenz.

Das ist alles von der Universität von Barclay, die BSD-Lizenz.

Und MIT, ja, ist halt, ja, MIT, ich finde das ja immer sehr lustig.

Harvard und MIT sitzen in der Ort, wenn du mal dir überlegst, wo liegt das MIT?

Jeder weiß, was die Harvard-Universität ist und die MIT University hat man eigentlich schon mal gehört.

Die Stadt, die sind, die liegen tatsächlich nebeneinander und die Stadt heißt Cambridge.

Und da muss man immer aufpassen, wenn man so einem Universitären unterwegs ist, hat man jetzt eine echte Cambridge-Universität, also die in England, die ja auch nicht ohne ist, die will man ja manchmal auch wirklich haben.

Oder hat man da wirklich wieder MIT und Harvard, weil die auch gerne unter Cambridge dann irgendwas veröffentlichen.

Das ist auch immer liegt im Übrigen in der Nähe von Boston, falls es noch einer fragt.

Genau.

Und nee, aber das ist, die kenne ich jetzt gar nicht, die Lizenz.

Ich glaube, das ist für mich, also BSD und MIT sind fast die denn, also das ist irgendwie Patent oder ja,

das ist.

Nee, das Apache macht noch diese expliziten Geschichten mit den Patenten.

Aber also MIT, äh, BSD weiß ich jetzt gar nicht genau, ist aber auch, vielleicht die liberalste ist wahrscheinlich MIT, das ist eigentlich quasi nur Copyleft, da steht nur drin, du musst halt sagen, darfst du es nicht entfernen, aber ansonsten

willst, glaube ich.

Oder nicht

mal das hineinfallen.

Die BSD ist, glaube ich, nur lass meinen Namen in Zeichen.

Das ist ja unterschiedlich.

BSD muss Namen drin bleiben, bei MIT ist es völlig egal.

Ja, ist bei Python übrigens auch so, Python hat auch die Python-Lizenz, aber es ist auch einfach nur BSD.

Ja, ja.

Wir haben irgendwann vor etlichen Jahren mal auf einmal war das alles nicht mehr BSD-Lizenz, sondern jedes Projekt hatte seine eigene Lizenz, was aber eigentlich die BSD-Lizenz war.

Ich nehme mal an, da gab es irgendwelche Namensgedönsgeschichten.

Keine Ahnung.

Und ich sag auf jeden Fall, von wem es gewesen ist, wenn du das sagst, was du machst, was du bist.

Ja, irgendwie so.

Ja, interessant.

Ja, es war schon relevant, wenn man das als Unternehmenskunde nutzen möchte.

Also ich war mal in einem Unternehmen als Diplomant damals.

Die hatten wirklich überlegt, aus dem Maschinenbau dann irgendwann das mal, wurde das ja weiter automatisiert und so weiter.

Und die haben dann damals echt diese Diskussion geführt, was nehmen wir für Platinen oder was machen wir für ein Betriebssystem auf unsere Platinen oder auf unsere Hardware drauf.

Und da war eine Diskussion Linux versus BSD.

Und die haben sich dann für BSD entschieden, weil ein abgespecktes Linux kriegst du ja auch hin.

Und es war damals ja auch noch nicht so groß.

Eben wegen der Lizenz, weil die das auch ohne Probleme dann in jedes der Geräte, die du heute in jedem Handel kaufen kannst, auch einfach drunter legen kannst.

Und ich meine, viele Autos nutzen auch BSD-Lizenzen.

Also das ist ganz, ganz spannend, wo du überall BSD drauf hast.

Das ist sehr, sehr interessant.

Du kommst ja heute gar nicht mehr dran.

Früher haben wir ja uns ja immer noch den Spaß gemacht, die Geräte auseinanderzubauen und zu gucken, was da drauf ist.

Das stellen die Hersteller ja heute, kommst du da nicht mehr so ohne weiteres dran.

Ja, oder dass du einen Rest Api dann irgendwo.

Du hast ja du hast halt ganz viel BSD.

Und wenn du ja eine Datenbank brauchst, eine etwas größere, dann hast du auch ganz häufig Postgres.

Das ist interessant.

Und wir haben jetzt noch zwei Sachen auf der Liste, die da vielleicht ganz gut reinfallen.

Also Maria, wäre das Postgres, wer vielleicht hast.

Also da hatten wir schon mal kurz was anderes NoSQL.

Achso, ja, also da gibt es jetzt nicht ganz viel zu sagen.

Es gibt halt neben den relationalen, die sich, also diese, ja erstmal ist ja NoSQL ist ja not only SQL.

Und da fanden die hierarchischen Datenbanksysteme, wer das mal gelernt hat, hierarchische Datenbanksysteme, sowas wie LDAP oder auch das Dateisystem, das ist auch ein Datenbanksystem, die waren dann plötzlich NoSQL.

Das fanden die sich überhaupt nicht mehr mit zurecht, weil, ja, not only SQL.

Und nein, es gibt halt tatsächlich sind dann so 2007 hat das so ein bisschen begonnen oder seit 2007 hat sich das angefangen zu etablieren.

Meines Wissens sind das dokumentenbasierte, von der Technik her dokumentenbasierte Datenbanksysteme und Graf-Datenbanksysteme, die grafenbasiert sind.

Und das Grafenbasiert habe ich vorhin schon mal so versucht.

Das sind dann so die Klassikerkunde, Kunden, die das gekauft haben, haben auch das und das gekauft.

Das ist so das klassische Beispiel dafür.

Das könnte man wahrscheinlich auch in einer normalen SQL abbilden.

Ja, da kriegst du aber die Krise bei, wenn du das abbildest, in einer normalen SQL.

Die Brabys dann zu groß werden oder die Joints zu groß werden?

Ja, ja, du spielst dann ja mit Matrizen am Ende und weißt der Kuckuck was, du brauchst ja unendlich viele Tabellen.

Also da wird es echt, das ist das Grafendingen.

Und wenn du dann mal so heute in größere Firmen guckst, ich nenne jetzt keine Namen, das darf ich jetzt ja wahrscheinlich nicht.

Die haben immer Kombinationen.

Also ich sag mal, so ein so ein Webanbieter, der hat ganz, ganz häufig Kombinationen.

Also für solche Sachen hat er dann eine Grafdatenbank und ansonsten eine relationale.

Für das ganze Kunden- und Verkaufsabwicklungskips hat das Relationale.

Und was dann immer noch Material vielleicht auch.

Und das kann man dann auch verknüpfen.

Die nutzen ganz viel.

Meine Erfahrung ist, was sie da ganz viel nutzen, ist von Apache.

Das ganze Hadoop mit H-Base, HGraph und wie sie alle heißen.

Also die nutzen sowohl, die meisten Firmen nutzen sowieso Maria und Postgres.

Also du hast sowieso da, also du hast nicht mehr nur ein Datenbanksystem, du hast halt ganz viele.

Und dokumentenbasiert ist von daher interessant.

Wir bei Postgres empfehlen ja immer Elasticsearch.

Das ist nicht, dass du Dokumente ablegst.

Also Dokumente könnten jetzt, ich nehme immer ganz gerne auch Bilder als Beispiel jetzt.

Bilder oder auch irgendwelche langen Textdokumente, PDFs oder so.

Aber das Gute an dokumentenbasierten Datenbanken ist, dass du in den Dokumenten suchen kannst.

Das heißt, du kannst mir sagen, gib mir alle Bilder, die den Farbcode rot haben.

Oder wo rote Pixel drin sind.

Das kannst du natürlich nicht in der relationalen Datenbank legst du das Dokument so als Blob ab.

Und du kannst nur das Dokument, du kannst aber nicht reingucken in das Dokument.

Du musst halt vorher beim Speichern reingucken, müsstest du quasi den Link zu dem Dokument in die Datenbank schreiben.

Ja, aber dann weißt du, du sind immer noch nicht alle Farbpixels raus oder ähnliches.

Ja, die muss ich ja mit einem anderen Speicher bedanken.

Ja, aber bei der Dokumentenbasierten oder wenn du PDFs, dann kannst du in den PDFs auch suchen.

Wenn du da Text hast.

Wobei das bei PDFs heutzutage wieder schwierig ist, weil ganz viele PDFs aus Kopierschutz als Bilder sind.

Das ist dann auch, wenn du die kopieren willst.

Aber das ist sowas, wo du dokumentenbasiert natürlich super für gebrauchen kannst, wenn du in den Dokumenten selber suchen willst.

Gib mir jetzt Gesichtserkennung, ganz klassisch.

Das ist sowas, wo du dann dokumentenbasiert hast mit Farbcode und mit was auch immer.

Gesichtserkennung wäre jetzt sowas.

Wobei ich dann nicht weiß, wie ich glaube,

speicherte bestimmte Punkte wahrscheinlich und dann die Winkel dazu kommen.

Ja, aber das ist jetzt was, was mir einfällt, wo du so bei Bildern ganz viel machst, das ist das.

Es gibt natürlich Dokumenten, MongoDB ist MongoDB ist dokumentenbasiert.

MongoDB ist natürlich sehr extremst umstritten.

Wie gesagt, die Firmen, die ich kenne, die haben dann da aus der Apache-Geschichte Hadoop und so weiter.

Da gibt es auch mal so.

MongoDB umstritten?

Meine Erfahrung mit MongoDB ist, dass es extrem RAM-lastig ist und auch sehr RAM-aggressiv ist.

Aber es gibt da tatsächlich Tests von großen Firmen, die mit F anfangen oder mit B anfangen oder ähnliches, die MongoDB auch wirklich auf die kleinsten Niere auseinandergenommen haben oder mit G anfangen, wo es dann auch mal Dokumente zu gab, warum sie das dann jetzt nicht einsetzen.

Und also was ich halt hatte, ist, es gab auch eine Zeit lang Hoster, die gesagt haben, du darfst keinen Tor-Server auf deinem Server machen und keine MongoDB.

Gerade in VMs, weil sie dir den RAM vom ganzen Host mit wegziehen oder ähnliches.

Auch weil MongoDB am Anfang halt keine, default-mäßig keine Authentifizierung hatte.

Du konntest sie einfach drauf verbinden.

Irgendwas war da ja.

Das war so ähnlich wie bei MySQL auch, weil da war es am Anfang auch so.

Naja.

Aber wie gesagt, die meisten greifen dann aber tatsächlich im professionellen Bereich auf dieses ganze Apache Age-Stoop, Age-Base, A Gratch, Graph und was weiß ich was zurück.

Neo4j ist, glaube ich, auch Age Graph.

Das hängt irgendwie zusammen bei den Grafenbasierten Elasticsearch, ist so ein klassisches Dokument, ein Ding zum Suchen in Dokumenten.

Also da gibt es verschiedene.

Da müssten wir jetzt auch nochmal eigentlich im Einzelnen nochmal, wie man das dann mit dem Begriff ist.

Ah, da bin ich aber auch nicht wirklich so.

Da ist halt das Problem, dass es da ganz viel Software gibt und dass du da, deswegen sage ich immer, man muss das dann auch heutzutage den jungen Menschen beibringen.

Es gibt halt nicht nur relationale.

Es gibt halt diese anderen und wenn ihr die wirklich braucht, du kannst die nicht alle im Studium lernen.

Also da gibt es dann GQL und so weiter.

Ich weiß nicht, ob das auch sinnvoll ist, die alle im Studium zu lernen oder hinterher Kurse dafür anzubieten, wie du es programmierst.

Gut, wenn du jetzt Programmierer wirst, ist es natürlich sinnvoll, dass du es noch lernst.

Ich weiß es nicht.

Ja, und wenn man es braucht, vielleicht, ne?

Ja, wenn man es braucht, dann muss man sich da mal reinfuchsen.

Ich weiß auch nicht, wie viele Schulungen es da schon gibt.

Also ich weiß, dass Couch.dB da mal eine ganze Menge gemacht hat im Schulungsbereich.

Bei den CouchDB ist, glaube ich, auch dokumentenbasiert, für mich jetzt nicht alles täuscht.

Das Cassandra?

Das ist, das ist so ein Misch, glaube ich, aus beiden.

Ja, das ist, glaube ich, so ein sehr, das kann man halt sehr gut verteilen.

Das ist halt auch mehr, aber eigentlich eher so ein Key-Value-Store.

Aber ja, also es gibt ja ganz viele unterschiedliche Dinge.

Ich weiß nicht.

Ich glaube, das ist gar nicht so einfach, sich zu überlegen, was man da jetzt braucht, wenn man sich damit nicht so auskennt.

Ich glaube, wenn man sozusagen weiß, was man daneben hat, also wenn man das Problem hat, dann weiß man das.

Und wenn man das nicht weiß, hat man diese Post.

Das hat tatsächlich an der Uni dann so ein bisschen die Studierenden mit Noah, Quatsch, mit Neo4J spielen lassen.

Ich habe aber auch eher so einen Zugang zu den Grafen, als es zu den anderen.

Weil bei den anderen kann man sich auch besser vorstellen.

Die sind dann auch wahrscheinlich leichter im Selbststühlen.

Ich habe die also echt mit Neo4j da, die hatten es mal ein bisschen rumspielen lassen, dass wir es mal gesehen haben.

Und das ist ja auch schon mal was, weil damit du überhaupt weißt, das mal gesehen hast.

Was würde man denn jetzt nehmen?

Wenn man kann GraphQL mit ein bisschen rumspielen will, was würde man jetzt da drunter schicken?

Neo4J.

Das hat auch eine Oberfläche tatsächlich auch.

Also das ist das, womit ich rumgespielt habe bis jetzt.

Du meinst GraphQL-Dest von Facebook oder.

Zum Beispiel, ja.

Also als eine Sprache.

Das kenne ich gar nicht.

Ja, ja, das ist irgendwie so eine neue Geschichte, so quasi als Alternative zu JSON über so JSON-API.

Aber das weiß ich nicht, ob das gibt keine Datenbank, die sowas direkt, glaube ich,

außer NeoProJ?

Vielleicht kann die das, ich weiß es nicht, vielleicht gibt es da irgendeinen Adapter oder so.