Transcript: PostgreSQL und MariaDB

Ja, hallo liebe Hörer und Hörer, herzlich willkommen beim Paisen-Podcast, Episode 43.

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

Und wir haben natürlich wieder den Jochen da. Hallo Jochen.

Hallo Dominik.

Ich bin der Dominik.

Und die Susanne ist heute dabei.

Hallo Dominik, hallo Jochen.

Hallo Susanne.

Ja, haben wir News?

Wir starten immer mit 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 irgendwie.

Was in der letzten Zeit so passiert ist.

Ja, ich mache hier 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's

halt auch tatsächlich direkt Unterstützung von PyTorch

aus. Und

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

Dann ist das natürlich super wichtig, ja.

Ja.

Ansonsten, ich meine, wenn ihr mal

dieses ganze Machine-Learning-Thema

und so interessant findet,

ich letztens, kann ich

den Robot-Brains-Podcast empfehlen von

Peter Abiel und da war

letzte Woche war da irgendwie Jeffrey Hinton

zu Gast oder es gibt jetzt zwei Episoden.

Das war, ja, 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 jetzt eigenartigerweise erst davon erfahren oder vielleicht haben wir das ja auch schon erzählt, das weiß ich nicht so genau. Es gab ein Paper in Nature, NumPy ist jetzt tatsächlich als quasi Artikel irgendwie in einem renommierten Magazin erschienen.

Damals, Travis Oliphant hat da ja

seine Doktorarbeit für abgebrochen und ihm haben alle

gesagt, bist du verrückt? Irgendwie

sowas komisches zu machen, Nampai, das interessiert

doch niemanden. Und

ja, jetzt hat das doch nochmal auch akademische

Weinen irgendwie

gezeitigt. Das war gar nicht so

schlecht. Spät, aber ja.

Tja.

Genau.

Sonst habe ich auch eigentlich nicht so wirklich was.

Wir wollten nochmal, vielleicht Blührepeisen haben wir ja schon ein paar Mal

eingeladen. Blührepeisen. Bist du jetzt eigentlich da oder

weißt du noch nicht? Also ich schon. Ich habe keine

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

Daher, wenn, dann bin ich alleine da.

Kurzfristig, okay.

Ja, kurzfristig könnte sein, dass das klappt.

Aber man muss halt nochmal gucken, weil Urlaubsplanungen anderweitig sind.

Ansonsten müssen wir alleine ein Bier trinken gehen.

Also meine Unterkunft ist nicht weit von der Brewdog-Bade entfernt.

Ich habe übrigens nachgeguckt, da gibt es keine Zimmer mehr in dem Hotel.

Oh, ausgeworfen?

Ja.

Okay, wow.

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

So schnell waren wir nur nie, drei Minuten.

Wir könnten auch noch irgendwie, es gibt jetzt auch eine

Postgres 15 Beta, glaube ich.

Da könnten wir eigentlich schon eine Überleitung machen.

Oh.

Was ist denn in der Postgres 15 Beta drin?

Weißt du das? Das weiß ich nicht.

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

Ja, dann machen wir doch das.

Dann gehen wir da direkt über.

Dann machen wir doch genau das.

Hauptthema.

Hier steht ja, bei Postgres 50 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 sage immer, du kriegst ihn zurück, also da kriegst du dann eine E-Mail, was mit dem Patch ist, ob der so in Kiki ist oder nicht okay ist.

Wenn du da eine Klammer ans Ende gesetzt hast, das sind die neue Zeile, 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 Mars 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 noch 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 in den zwei Tagen später, noch während der Schulung, kommt 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, 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 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, mit den Release Notes, was da passiert ist und was nicht.

Auf alle Fälle, ab Version 13 ist Postgres noch mal 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, ich würde sagen, jetzt haben wir die News auf jeden Fall durch.

Ja, ja, ja.

Und können wir anfangen mit unserem Thema.

Ja.

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

Datenbank, ja. Speziell im Allgemeinen

oder auch noch ein bisschen im Detail.

Du hast ja ganz viele Erfahrungen mit Susanne.

Du kennst halt die ganzen Unterschiede

zwischen Mü,

Maria. Soll ich das erzählen?

Ja. Also ich habe,

ich erzähl mal kurz die ganze Geschichte.

Ich hab 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 Informix?

Informix ist ein konventionelles 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 welches Datenbanksystem

ich dann nehme. Und es gab dann

damals schon MySQL so ein bisschen.

Und es gab ein bisschen PostgreSQL.

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

PostgreSQL genommen und

es war damals wirklich noch ziemlich

identisch. Ich habe später

erfahren, PostgreSQL und Informix

hatten denselben

Urkurs. 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 noch nicht drauf. Ingress.

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 Informix

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 einspülen 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

ja, 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, dass irgendeine Update-Syntax

eine spezielle wäre Standard,

aber Postgres konnte das nicht und

dann hieß es,

ja, entwickle doch.

Und ich hatte dann einen Mentor dazu,

einen der großen Entwickler von PostgresQL,

mit dem habe ich mir ein Büro geteilt.

bestimmt 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

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

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

Er 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, ich, 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, wie kannst du bei uns anfangen, hab mir das dann natürlich erstmal überlegt und musste dann 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-in-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 die dann standen 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 genauer erklären, 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,

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, das 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 Fun 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 Langkorn heißt.

International,

keine Ahnung. Ist ein klassischer

Börsending, wenn eine Firma

und dann haben sie aber

beschlossen, sie verkaufen es, die Aktionäre

das war ja schon irgendwie

haben dann beschlossen,

sie verkaufen es an Sun Microsystems für

zwei Milliarden. Zwei Milliarden

finde ich schon eine ganze Menge.

Initial Public Offering.

Initial Public Offering, genau.

Und dann

haben sie es verkauft an Sun Microsystems

und ein Jahr später ist Sun Microsystems

von Oracle gekauft worden.

Und

jetzt 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 Montevideo News.

Vielleicht noch ganz vorher, also MariaDB war vorher Open Source?

Nein, nein, nein, MySQL.

Das war alles MySQL noch, MariaDB komme ich jetzt zu, also da irgendwie in diesem Sun Oracle hatte der Monty Vitenius, der Urentwickler, einer der Gründer, der Urgründer von MySQL.

Dessen Tüchter dann auch.

Das sage ich gleich auch noch, genau. Der hatte irgendwie den Code aber geforkt von MySQL, den er forken konnte legal und hat dann MariaDB gegründet. MariaDB, weil er hat drei Kinder, My, also M-Y, aus Englisch My, Schwedisch eigentlich My.

Die jüngste Tochter heißt Maria und er hat auch einen Sohn, der heißt Max. Es gibt auch einen MaxDB, ich weiß nicht, ob es 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 eingestompft, als ich bei MySQL 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 MariaDB 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,

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

Also quasi 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 Open Office-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

halloatpaisenpodcast.de. Ja, genau.

Und ja, so war das. Und ich

bin dann zurück zu meinen

Urzeln. Ich habe mich dann mit einem

Franzosen, mit einem Engländer,

mit noch einem zweiten Deutschen

und einem aus den USA

und einem

Italiener zusammengetan.

Und wir haben dann PostgreSQL

erst mal. 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 machst bis heute im Grunde PostgreSQL und MariaDB 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. Nein, ich fahre 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, Sun 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.

Ja, Ansi, also Ansi ist an Microsystem 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.

Und bei Postgres war immer das Problem, das wollte der Standard nicht, weil das ja keine Legal Entity hat, also macht ja kein Geld, ist ja irgendwie Open Source, da war etwas komisch. Und dann hatte Sun auch noch JavaDB 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. Also ich hatte Sergey 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 später, hast du Lust? Und ich sagte, ja.

Und dann hörte ich nur, dass Sergej sagte, ich habe da jemanden. Also es muss so gesehen sein, dass Peter dann wohl von PostgreSQL, den hatten wir mittlerweile zusammen geholt, das war auch lustig, mein alter Kollege Peter Eisentraut, mein uralter 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 Peters Stimme, 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 fragten, wen meint ihr denn jetzt? Und dann kam raus, ja Susanne. Und so bin ich dann erstmal in diesem Ansiedgremium 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 oder zwei Hersteller. Wenn du drei Gruppen hast, kannst du erstmal einen nationalen Standard gründen. Also bei DIN, die brauchen auch immer drei und das dürfen nicht drei Universitäten sein. Irgendwer muss da schon mal Gewinn bringen mit was zu tun haben.

Und dann hast du nationalen, 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 Datenbankhersteller, das ist eine riesengroße Gruppe gewesen. Da saß auch Microsoft drin, die haben kaum was gesagt. Im Grunde haben sich da immer 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.

Wer hat mein Geld, da kann man mir einfach was auf den Stand nehmen.

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

Dann kam Deutschland auf mich zu und sagt,

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 Schrauben-Norm gegen Japan gestinkt hat oder gegen das asiatische Land. Ich weiß nicht mehr, welches genau. Also so, wir standen da, wir kannten diese Schrauben-Norm nicht mal.

Vielleicht nochmal genau 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 du egal, welches Datenbanksystem du hast, dass 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, so ein Insert funktioniert auch meistens noch, dass das Grund-SQL funktioniert meistens noch auf allen gleich.

Aber in den Dialekten weicht das dann von Standard ab, oder?

Ja, genau. In den Dialekten wird es anders.

Und das kommt daher, weil natürlich,

diese Gremien, da wird dann ein 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.

MySQL 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 kriege ich, wirft er die ersten drei weg und er gibt mir den vierten Wert, bei der Offset dann drei ist. Also super so ein Tax. 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, bring 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-Rows

X-Next-Rows-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 bei sämtlichen

Zeitgeschichten.

Wenn man ein Date bei Oracle eingibt, ist das

immer mit Uhrzeit 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. Ich sage ja, so ein Insert Statement, 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

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.

Nein. Auf Kreta.

Ja, sagst du so.

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.

Während Deutschland, wir waren damals zu zweit, es war noch die Uni Aachen damals mit in dem Gremium, als ich da drin war. Die haben gesagt, wenn ihr beide euch einig seid, einer von Eureka und ich, dann passt das schon so ungefähr. Und auch die anderen Länder waren kleiner. Aber wie gesagt, IBM und Eureka, die saßen fast in jedem Land, hatten die versucht. 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.

Wir haben den Peter sowieso schon mit dazugeholt von PostgresQL. Der hat eine Zeit lang 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. Ne, MySQL tatsächlich, nicht MariaDB, weil es wurde ja von Auric bezahlt.

Und natürlich hat das Gremium aber mich auch eher dann zu PostgreSQL befragt, weil das war hinterher, als das 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 waren die immer sehr froh, dass ich dann noch mit drin war, aber irgendwann bin ich dann da ausgestiegen, weil ich dann auch nicht mehr, ja, wie gesagt, das ist eine teure Angelegenheit.

Und mittlerweile ist der Peter Eisentraut da mit drin, dann brauche ich dafür PostgreSQL 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 das 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 heißt Sequence Query Language?

Gar nichts, das heißt einfach nur SQL.

Das steht immer bei Wikipedia,

Standard Query Language,

Structured Query Language, irgendwie sowas.

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 glaube ich auch irgendjemand 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.

Das hat mich geändert.

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.

Spannend mal

die Geschichte vom Datenbanksystem.

Ja, wir können natürlich sowohl

Postgres als auch Maria, also ich mache

überwiegend heute MariaDB

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 des Open Source.

Hat sich da in der Lizenz

mal, weil MySQL hat ja so ein bisschen

früher eine etwas komische Lizenz.

Das war, oder im Vergleich

zu anderen, also jedenfalls im Vergleich zu Postgres,

Postgres ist ja sehr liberal, aber

eine super Lizenz.

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

dann abgesprengt, es ist net BSD drauf,

wegen der BSD-Lizenz.

Und dann, wenn sie ein Datenbanksystem

wirklich brauchen, dann eine Postgres auch

wegen der Lizenz.

Auf der Apple Watch ist SQLite, wird auch

gerne verwendet. Also wenn die

Schritte gezählt werden, auf der Apple Watch

macht das eine SQLite.

Aber ja, Postgres auf einer

Uhr ist vielleicht auch ein bisschen übertrieben.

Ich darf nicht unbedingt über Referenzen reden, aber

es ist schon spannend, wo Postgres da so

überall drin sitzt.

Deswegen MySQL und MariaDB, die sagen ja immer

oder MySQL hat sich damit immer gebrüstet,

vor allen Dingen Oracle und MySQL,

Die weltverbreitetste Datenbank, ich weiß das gar nicht,

weil Postgres, 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öntorp 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,

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

mach nicht alles

im Relationalen, mach das im Relationalen,

was du im Relationalen abbilden kannst

und wenn du was

Graf, was besser in Grafen

abbilden, wenn es bildet, ist ein Grafen 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 ich, genau,

also da,

ich finde Postgres ist eigentlich

immer ganz schön, oder sagen wir mal so,

weil es halt so ein bisschen ähnlich ist,

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 on 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 Poskos 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 MariaDB besser zurecht. Das finde ich jetzt

spannend. Welchen Nasenfaktor gibt es

zu MariaDB? Welchen Postgres?

Postgres ist, es kommt

darauf an, wo du herkommst, also

von welchem Daten, auf welchem

Datenbasis-System hast du gelernt

Wenn du jetzt wirklich aus

der DB2

Informix 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 LempStack, oder?

So PHP, was weiß ich,

ja, Lemp,

ist vielleicht MariaDB für dich

intuitiver.

Also es kommt ein bisschen

drauf an, wie Hardcore hast du SQL

gelernt? Auch.

So 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?

Ich habe da wirklich schon,

wenn ich so junge Menschen, wenn die so

lernen, SQL oder Datenbank

Vorlesungen, es ist schon

sehr spannend. Dann hat man so ein reines

Oracle-Dialekt.

Teilweise.

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

lernen. 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 einen 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 da 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ührt mit SQL. Das war ein

SQL-Tutorial. Das will ich sehen. Genau, das

finde ich cool, weil ich finde Gamification ganz

gut. Wenn du bei mir die Schulung buchst, dann kriegst du dann

einen Bindfaden und darfst dann an einer

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 eine Ausbildung bei

der IHK oder so,

teilweise, wenn du da reinguckst,

Also 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 Eureka-Lastik

oder ganz stark MySQL-Lastik hast du auch.

Häufig, was ich traurig finde

in der heutigen Datenbankausbildung 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 Datenbank-Vorlesungen, die ich gegeben habe,

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

Datenbank ist ein Pflichtfach. Das ist ja

sowas. Nur, dass du es zumindest schon 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 Murder Mystery.

Ah ja. Das ist das erste.

Da geht es halt darum, den Mordfall, also Murder

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. Das ist sehr interessant.

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

Ich habe eine Zeit lang auch mal

irgendwie sowas gemacht. Stell dir vor, du bist in deiner Küche

und dann duftest du deine eigene Küche.

Wo sind die Teller und so weiter.

Das habe ich auch schon mal gemacht.

Aber das finde ich cool, ja.

Und ich habe noch ein zweites Story mal gemacht.

Das ist auch sehr schön. Select Star, SQL heißt das.

Da geht es darum,

das ist ein bisschen ein 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 einfach die eine Aufgabe gegeben.

Ich glaube, es war eine Umsatzstatistik.

Da habe ich die Sterbestatistik draus gemacht.

Es war dann auch zwar makaber,

Aber es war für die leichter Nachfolge zu vollziehen

als irgendwas BWL-lastiges.

So, was passiert jetzt?

Wie viele Menschen sterben da jetzt von?

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 einem Teelöffel.

Oder wo die Menge fünf ist.

Brauchst du aber heute doch.

Doch einzeln normalisierst du tatsächlich auch aus heutzutage,

weil Rezepte, dann 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 brauchst 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,

gib mir alle Rezepte, wo eine Prise drin vorkommt, das Einheit.

Ein Quäntchen Glück.

Ja, 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, du hast hier noch ein View oder ähnliches, dann ist ein Kochbuch wieder auch zu viel.

Ich glaube, wenn du so eine volle Datenbank hast, mit der interessant ist, dann ist zum Lernen vielleicht besser, also wenn das nicht nur so trockene BWL-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 mag.

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 ja mit einem Meta.

Nö, das kannst du ja mit, wann du die Zeile geendet hast,

du on update, da machst du noch eine Spalte mehr dran

und dann hältst du das dann fest last update.

Genau, aber das muss ja ein Modell mit drin stehen haben.

Ja, ja, eben, deswegen, das sind dann aber so Sachen,

da gehst du dann vielleicht noch mal drauf ein,

wenn du so, also dass du ein bisschen mehr auf Datenschutz eingehst.

Du machst immer dieses Beispiel, was sind 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, ne, 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 noch mal kurz

Transaktionen, das müssen wir gleich alles noch mal

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 hab vielleicht eine pessimistische,

etwas pessimistische

Ansicht dazu, dass man, ich glaub, ich weiß nicht,

ob man das so trocken lernen kann,

also, oder vielleicht bin ich einfach nicht der Typ

dafür. Ich kann das nur lernen,

wenn ich das tatsächlich brauche.

Und es dauert auch lange.

Ich habe

angefangen, mich mit diesem Thema zu beschäftigen.

Ich fühle mich einigermaßen sicher.

Bei relationalen Daten machen wir das eher so Jahre.

Und das waren,

wenn man jetzt eine Vorlesung

hört oder eine Prüfung schreibt,

das ist aus meiner Sicht nicht so richtig gut möglich.

Ihr müsst jetzt aber wieder verstehen, dass wenn Jochen meint,

dass er so einigermaßen sich wohl fühlt, ist er derjenige,

der das richtig aus dem Schlaf dann...

Nein, einfach so, dass man halt ungefähr weiß,

was man da tut, dann das ist...

Dann hatte ich einen guten Prof, also ich

habe das relativ schnell, 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 sofort erklären, bitte, was

ist Mengenlehre? Mengenlehre

war in der ersten

Klasse, du hast da so

ovale gemalt,

einen links, einen rechts, das war deine

Menge mit den roten

Plättchen und das war deine Menge mit den

blauen Plättchen.

Und dann wolltest du jetzt wissen,

ja, gebe mir alle Plättchen,

die die Dreiecken haben.

Und dann hast du die übereinander

gelegt und dann hast du die Schnittmenge aus dem

roten und dem blauen Plättchen mit der Schnittmenge

die Dreiecken haben. Und die wurde dann lila.

Nein.

Dann hast du da die viereckigen drin und die fünfeckigen

und die Kreise hast du da beides und die

dreieckigen waren halt die Schnittmenge.

Das ist Mengenlehre. Das nennt man auch

so, wie heißt das,

Kombinatorik heißt das dann im Studium

oder

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, entweder hast du die Schnittmenge

Join, 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 darunter steht.

Ja, aber du hast vorher was gefragt

zu SQL.

Ach so, ja genau.

Ich habe halt im Studium

und auch später, wenn ich mal

junge Menschen ausgebildet habe,

es gab, du hast

entweder 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 immer 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 deine Noten nach der

Normalverteilung verteilen.

Und ich sage, super, du hast nur welche, die haben es verstanden

und nicht, da kannst du ja vielleicht

eine Nuance, vielleicht 1,3 oder 1,7

draus machen oder halt, nee.

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.

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 sie 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 es ja nicht kannten.

Und dann hat man es wieder aufgegeben

und jetzt fängt man dann wieder mit Zellen.

Also Zellen kam es 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,

dass 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 sie auch dann später

zum Beispiel für SQL Kombinatorik

und die hatten weniger

Schwierigkeiten damit. Ich dachte, na,

das ist ja wie Mengenlehre, so ungefähr.

Da ist nur ein bisschen, dass du nicht mehr

nur rote und blaue und bunte Plättchen hast

und Dreiecke und Vierecke, sondern

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.

Und aber...

Ich frage deswegen, weil vielleicht konnte man sich ja vorbereiten

zu sowas, indem man nochmal sich so

diese Basismengenlehre, wie du sagtest,

mit den unterschiedlichen Schnittmengen, Kreisen

vor Augen führt, um dann

zu überlegen, wie das in der SQL ausfällt.

So ein, jemand, der sowas noch nie

gesehen hat, der irgendwie einen komplexeren Outer-Join

ein bisschen zu fassen sieht,

der ist vielleicht erstmal befordert.

Ich habe da auch eine Folie für, wo ich

wirklich das wie in der Schule mit den Ovalen,

ich nenne das immer Eier, mit den

Ovalen und Schnittmenge und was

ist A und B, A oder B

oder A und nicht B und solche

Geschichten.

Es ist sehr lustig,

es 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 der Anwendung braucht, ist dann was anderes.

Aber nur, damit man dann mal die Logik dahinter versteht.

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

Es gibt ja auch beim Programmieren,

wenn ihr so Algorithmen habt in der 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.

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

Aber auch das,

wenn du es einmal verstanden hast, dann

ist es auch nicht so schwer.

Was der Normalisierung überhaupt ist,

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

Also wenn ich das so laienhaft 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, ich kann dir das jetzt erstmal, ich will das 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 sagen, was die erste und die zweite sind.

Musst du es jedes Mal nachgucken, wenn ich es schule.

Weil du brauchst 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 Postleitzahl Stadt, das Klassische, was du so in der 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 Osanbrücke.

675 ist ja ein Rekord, finde 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 dann das Wort Bielefeld einmal drin stehen und dann hat Bielefeld vielleicht die ID 33615, weil das die Postleitzahl ist und oder wonach man das auch immer nur bei Städten wäre, Postleitzahl wäre eine super ID, kann auch eine andere Nummer nehmen, die 760 und dann steht halt bei der Tabelle mit der Person unter Stadt nur 760.

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 Bieleflät geschrieben hat, dann ist das halt überall Bieleflät.

Also das ist das.

Einfach zu ändern.

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

So ungefähr.

Wie kann das denn sein?

Ich hätte auch Düsseldorf nehmen können,

aber bei 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 tippst immer Osanbrück.

Das ist tatsächlich der klassische Tippfehler.

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

Da 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üchenwaage ist umgedreht 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ülmaschine, nein, ich hatte mal eine 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

in einem ordentlichen Schrank.

Du sortierst in deiner Küche,

ich habe jetzt die Küche genommen, ich hätte auch deinen Kleiderschrank

nehmen können. Du sortierst 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 nimm mal die ganze Wohnung,

da sind nur deine Unterhosen drin.

Die mischst du nicht.

So.

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

Aber das ist erst mal so, dass du das so weit runterbringst,

dass du das, was zusammengehört, diese Einheit,

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.

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.

Das finde ich jetzt interessant, weil ich glaube,

das ist sehr, sehr 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üsste jetzt dann vielleicht doch teilen

zwischen Weingläsern und Biergläsern und Wassergläsern.

Dann machst du halt zwei Tabellen. Aber woher weiß

ich denn jetzt, ob Wasser 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, nennen wir eine

Automarke, nur Mercedes haben.

Bestimmt ein Typ 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 dann nur die Nummern drin, auch noch fünfmal falsch geschrieben wahrscheinlich, ne?

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

Also breit hast du viele Spalten.

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.

Aber das ist alles in eine Tabelle und dann sucht jemand,

möchtest du einen Käufer haben, der jetzt bestimmte Eigenschaften daraus sucht.

Ich kann dir 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 aufmachen.

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 dazu kam, waren sie dann mittlerweile, weil sie Konkurs 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 PostgreSQL genau das gleiche Problem kriegen wie mit MySQL war es damals noch.

Ich bin dann nach Hause gefahren und dann kriegte mein britischer Kollege einen Anruf, der konnte die Consultant verscheißen. Ich habe ja nicht das gesagt, was ich hören wollte so ungefähr. Schick mal einen anderen.

Und mein britischer Kollege hat dann einen ganz jungen dahin geschickt, 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 mit 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. 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 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 dann gesagt, hat er gehört, was die vorher beraten, hat er gesagt, oh ja, ja.

Nee, nee, das brauchst 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 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, 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 hochscrollt 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, ist es vielleicht sinnvoll, diese Tabelle mal mehrere aufzuteilen.

Ja, das vielleicht unter Kategorien zu fassen.

Ja genau, also das Normalisieren heißt einfach, du fasst es irgendwo so zu Kategorien zusammen oder das zusammen, was zusammen gehö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,

äh, dumm, fünfmal die

Ärzte, kenn 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,

sag mal, erst mal, 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 erst schon 127

Zeilen, wo du die Ärzte doppelt

zigfach drin hast und dann

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 erst mal die

Interpreten raus,

machst da von der eigenen Spalte, da hast du

eine Interpretenspalte. Kannst du vielleicht noch mal die Adresse

oder wo du dann die

Autogrammkarten kriegst oder was auch immer,

je nachdem, warum du jetzt die Musiktitel sammelst,

noch mit dazu packen,

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 1

und dann steht in deiner Song-Tabelle

nur noch die 1 drin für die Ärzte

und die 2 für Rammstein

und die 3 für irgendwas.

Und die 27 für Helene Fischer

sowas in der Richtung. Also

hast du danach die Nummer und du kannst dann nachgucken,

wenn du dann hinter der Tabelle bist, okay, interpretest

Nummer, was hatte ich vorhin, drei

und dann guckst du in der anderen Tabelle nach, Nummer drei

ist,

habe ich vergessen.

Hatte ich überhaupt eine drei?

Weiß ich nicht mehr, aber eine zwei bei Rammstein,

das weiß ich noch. Und die drei ist dann

Sepultura, irgendeine Metalband. 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,

wir sind ja bei dem Titel im Grunde,

aber 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, so eine Zwischentabelle,

dass du das Album und die Band noch zusammenlegst,

dann 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 in dieser Zwischenstabelle 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 draufsteht, Album 1, Band 1.

Ach so, da hättest du es sowieso drin,

dann brauchst du es gar nicht.

Oder nur Album 1.

Und dann kannst du es dann noch mal weiter verlinken,

wenn du da jetzt nochmal, jetzt wäre das doppelt,

aber das macht man schon dann, das

demonymisiert 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

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

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

Also du hast Mehl und dann 300 Gramm,

wenn du jetzt die Zutaten zusammen mischt,

weil du ja diese Funktion hast,

ach, gib mal jetzt für zwei Personen oder drei

und teil mal, 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 dann mal gezielt Bottlenecks auch dir angucken kannst und sagen kannst, okay, da 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.

Ja, also die dritte Normalform ist eigentlich das, was du am Ende brauchst und du brauchst immer einen Schlüssel, jeder 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,

Volker-Meyer-Adolf-Straße 27 in Düsseldorf.

Jetzt hast du den Datensatz ausgesehen, fünfmal erfasst.

Er sieht aber identisch aus, komplett.

Fünfmal.

Du willst ihn eigentlich nur einmal haben.

Du musst ja jetzt die vier da rauskriegen.

Wie kriegst du 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 da eine Spalte davor sitzt, wo du dann eine Kennung rein hast.

Und dann hast du dann, Nummer 1 ist Klaus-Meyer, Nummer 2 ist Klaus-Meyer, 3 ist Klaus-Meyer, 4 ist Klaus-Meyer, 5 ist Klaus-Meyer und dann kannst du dann sagen, delete alle, wo Name Klaus-Meyer 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 Eindeutigkeit 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, diesen alleinigen. Das ist das noch, was dazukommt. Und dann hast du die dritte Normalform, du brauchst ein Primärkey und du musst, Primärkey heißt das auf Deutsch, 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, Normalisierung haben wir, glaube ich,

soweit verstanden, oder?

Ja, also, genau.

Also, ich meine, irgendwann,

ich habe dann irgendwie meistens,

wenn bei irgendeinem neuen Problem oder so,

da oft dann angefangen,

so ein Entity-Relationship-Diagramm hinzumalen oder so.

Und das, genau, das macht man dann eigentlich meistens.

Irgendwann hat man das dann so ein Gefühl,

wie das dann aussehen kann.

Das mache ich 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.

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 raushaben, was brauchen die

überhaupt alles in der Datenbank,

dann musst du noch gucken, meistens für die Firmen

mit, was ist überhaupt erlaubt, abzuspeichern.

Gibt es ja auch sowas

wie diesen

bei der Kreditkarte,

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-Lern zu tun oder mit

technischen Menschen, sondern mit anderen.

Aus deren

Sprachgebrauch rauszufinden, 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 kannst du ein Bottleneck haben, da kannst du was rein haben.

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 der 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, wie weit ist der Spielstand oder so weiter.

Und die mussten dann immer den Nutzer,

und wenn da auf eine Tabelle immer laufen,

zwei Millionen Sachen raufkommen oder noch mehr Spieler,

ist das natürlich etwas schwierig.

Und dann sind die hingegangen und haben die nix,

der Spieler dann noch mal 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 und gucken.

Ja, und dann, deswegen ist so ein Nick ändern bei so Spielen

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.

Was ich auch mal aus Versehen denormalisiert hatte,

war so eine Stempeluhr-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.

komisch, warum dauert das Update denn so lang?

Na, das ging relativ schnell,

es war ein guter Server, so viele Mitarbeiter

waren das nicht, aber dann so, ja,

die Stempelur lief auch erst irgendwie so

zwei Jahre, also es war nicht so schlimm.

Ja, aber zum Glück

gab es die Differenz noch,

also konnte ich dann ganz schnell mal

ein Update fahren, mach mal Start 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 ist ja eine Hitze, die die Differenz

ja gar nicht gebraucht, aber ich fand das

damals sinnvoll, sie mit abzuschleichen und ich rate

das auch bei einer Stempelung, jeden das gleich

mitzumachen. Doppeltet, besser

dann, ja? Ne, das ist auch teilweise

wie du es in der Anwendung brauchst, wenn du immer

diese Differenz brauchst, dann

brauchst du auch nur die Differenz abfragen

und musst nicht immer Start und Stop 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

da in Schutz und was weiß ich was mit berücksichtigen,

Deswegen hast du auch ganz viel in den Tabellen, fast jede Tabelle noch last updated und so weiter.

Update 3 updated.

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, wenn du einen Preis änderst, solltest du den alten Preis ja auch nochmal irgendwo sehen.

Ja, schon praktisch, dann kann man das auch 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 Geschichten.

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, für die Schlüssel, dass dann die Namen genannt werden. Ich hatte mal eine Firma, die hatte 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.

Ja, sehr gut.

Also das sollte man natürlich nicht machen, sondern 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,

Postleitzahlen sind auch super Schlüssel bei Städten.

Ist das sinnvoll, ein Datensatz?

Nee, das ist schon sehr sinnvoll, wenn das so eine ganze Zahl ist.

Jedenfalls, je nachdem, was man für einen Index verwenden will,

vielleicht auch drauf.

Aber zum Normalfall denke ich schon,

dass es vielleicht nicht so unpraktisch ist.

Ja, das wäre eine interessante Frage.

Also irgendwie sehe ich in letzter Zeit sehr häufig,

dass Leute UUID-IDs verwenden.

Also dann könnten wir den Hash nehmen.

bitte? 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 eigentlich das erzeugen möchte,

will man ja, dass sie eindeutig sind, hat aber keine zentrale

Datenbank möglicherweise.

Es gibt halt

diese Sache bei Postgres

und bei MariaDB und so weiter,

sogar im Standard gibt es den Datentyp Serial,

der soll einfach immer einen hochzählen

und das kann man

natürlich machen und wenn das völlig egal ist,

was du für eine Nummer hinterher hast,

nimmst du den

und zählst dann einfach mal, dann zählt der automatisch

beim Einfügen einen hoch und dann hat das

Ding eine eindeutige ID.

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 es halt, weil einfach

UUID ist halt so riesig. Das heißt,

wenn du das dann tatsächlich

als Primary Key hast, dann macht das halt Joins

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

da eh nicht das Bottleneck, aber

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,

so eine Eigenschaft will man ja oft haben, dass man nicht

sehen kann, wann

ein Datensatz eingefügt worden ist, weil an der 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

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

Das ist natürlich, wenn du dann so einen Support am Telefon

nennen sie mir mal ihre Kunden-ID und dann fängt

er da an, so ein Unix-Timestamp-Bot zu lesen.

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 dann liest, ist dann doch schon schwierig.

Also so viel,

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

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

so eine interessante Sache, weil was mache ich denn jetzt,

wenn ich die Postleitzahleneingabe

nicht kontrollieren kann, weil ich die irgendwo herbekomme

und dann hat irgendjemand dann D-Postleitzahlen

eingegeben oder sowas.

Und dann habe ich ja das Problem, dass ich dann

Doppelte habe, quasi.

Naja, es kommt darauf an, wie du die

Postsatz an der Datenbank abgelegt hast.

Ja, also in Malarbeit, wenn es jetzt sechs Zeichen,

ja, nein, dann geht es halt kaputt.

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,

ganz 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