Transcript: PostgreSQL und MariaDB

Ja, hallo liebe Hörer und Hörer. Herzlich willkommen beim Python 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 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, Jochen im Hintergrund, tippen.

Ja, ich mache hier schon mal die Kapitelmarken,

dann spare ich mir ein bisschen Zeit,

aber 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

das 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 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 Abiel und da war

letzte Woche war da irgendwie Jeffrey Hinton

zu Gast. Es gibt ja 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? 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 Olyphant hat da ja seine Doktorarbeit

für abgebrochen, weil die haben alle gesagt, so bist du

verrückt, irgendwie sowas komisches

zu machen, NumPy, das interessiert doch niemanden.

Und ja, jetzt hat

das doch nochmal auch akademische Weinen irgendwie

gezeitigt,

was dann gar nicht so schlecht spät

war.

Ja, genau.

Sonst habe ich auch eigentlich nicht so wirklich was.

Wir wollten noch mal vielleicht

Büropeisen haben wir ja schon ein paar Mal eingeladen.

Bist du eigentlich da?

Ich habe keine Unterkunft

gefunden, jedenfalls nicht,

sodass wir da alle hinfahren könnten.

Wenn, dann bin ich alleine da.

Kurzfristig, okay.

Könnte sein, dass das klappt,

aber man muss halt nochmal gucken, weil

Urlaubsplanungen

andere Weitige...

und der

Überleitung.

Oh.

Was ist denn in der Postgres 15 Beta drin?

Weißt du das?

Das weiß ich nicht.

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

Ja, also.

Hauptthema.

und zum Postgres.

Hier steht ja bei Postgres, 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 massiv 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

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 noch mal

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,

zu auskommen, 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 nochmal wahnsinnig

viel schneller geworden. Also ich kann

allen empfehlen, zumindest auf 13

abzugraben, wer noch

auf 9.6 ist. 9.6

müsste auslaufen.

Nicht richtig gerechnet habe ich jetzt gerade.

Ah, okay.

Ja, also ich würde sagen, jetzt haben wir die

News auf jeden Fall durch.

Und wir können noch anfangen

mit unserem Thema.

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

Datenpacken.

Speziell im Allgemeinen oder auch

noch ein bisschen im Detail.

und Python-Programmierung.

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

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.

Ingress heißt es.

Ich kam jetzt gerade zu schnell nicht auf den Namen.

Also Michael Stolbrecker hatte dieses Projekt mit Ingress. Michael Stolbrecker 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 nehmen 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 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.

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

ob es noch eine zweite Frau gibt

oder ob ich die Erste wäre.

Dann haben sie festgestellt, ich war die erste Entwicklerin,

die ein Patch dann committed bekommen hat

und in den Post-Restore-Code.

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

Leider ist was passiert.

Ich brauchte einen neuen Job

und ich kriegte dann

per ICQ

schrieb mich dann jemand an.

Wie war das nochmal? Oh oh.

oder so. 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, 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 es 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 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 genau erklären.

Ja, also MySQL

ist sehr, sehr schnell gewachsen.

Wir waren zum Schluss,

als wir noch MySQL, also MySQL ist in Schweden gegründet,

war 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

und Jochen unterhalten sich über die Programmiersprache Python

beschlossen, sie verkaufen es. Die Aktionäre

haben dann

beschlossen, sie verkaufen es an Sun Microsystems

für 2 Milliarden.

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

Könnt ihr euch vorstellen, dass wir mit Oracle

und Python.

und irgendwie den Code aber geforgt von MySQL, den er forgen 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 ein MaxDB, ich weiß nicht, ob es das noch gibt, aber das war eine Datenbank, die unter SAP oder im SAP-Unfeld mit war.

Ich glaube aber, 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, dass 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.

Also quasi komplett einfach

alle gekündigt. 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 hallo-at-python-podcast.de.

Ja, genau.

Und ja, so war das.

Und ich bin dann zurück zu meinen Nürzeln.

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

Es war so ein bisschen gemischt.

Die Firma heißt Second Quadrant,

ist jetzt EnterpriseDB

und

ich habe hauptsächlich Consulting gemacht,

weltweit,

für PostgreSQL. Also ich bin ganz viel

in 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 bis heute im Grunde Postgreskel 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 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 nämlich erzählen, du hast nämlich doch mal

diese ganze Reisetätigkeit vorher im

Zusammenhang

da mit dem SQL-Standard

gemacht. Ja, 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, das macht ja kein Geld.

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,

aber 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 sagte er

erzählte er mir groß, ja die suchen jetzt jemanden

der uns da

im Standardgremium vertreten kann

und irgendwie so in der Minute

hast du Lust? Und ich sagte ja.

Und dann hörte ich, dann hörte

ich, dass Sergey sagte

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

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 Peter stimmen. 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 alle anderen

fragen, wer meint ihr denn jetzt? Und dann kam raus, ja Susanne. Und so bin ich

dann erstmal in diesem Anziehgremium 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.

und Jochen unterhalten sich über die Programmiersprache Python

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

Google hat mein Geld, da kann man

mir einfach was aus der Stunde sagen.

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.

Weil die Länder machen immer die Vorschläge

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

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

Datenbank-System du hast,

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 sag mal, so ein Select

ist ja zum Glück auf allen

Datenbankensystemen

funktioniert es und Insert funktioniert auch meistens noch,

dass das Grund-SQL

funktioniert meistens noch auf allen

gleich.

Und

in den Dialekten wird es dann, weicht das dann

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

Weil der Offset dann 3 ist.

Super so ein Tag.

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-next-rows-offset-y.

Okay.

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 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, machen dann Alias draus

oder ähnliches. Aber zumindest

das Uhr, das Grund ist erstmal

dasselbe. Ich sage ja, so ein Insights-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

eine politische Geschichte.

und 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, das sagst du so.

Welche in Sylt?

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

Mehrheit hatten.

Deutschland, wir waren damals zu zweit,

es war noch die Uni Aachen,

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.

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 dazu geholt

von PostgresQL, der hat mit seiner

in Finnland gelebt und den haben wir aber immer

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

und Jochen unterhalten sich über die Programmiersprache Python

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,

wieso 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ß Sequel.

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 Sequel, aber war es nicht.

Was heißt das? Sequence Query Language? Gar nicht.

Das heißt einfach nur SQL.

Es 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 habe es erfunden Ich glaube ich habe auch irgendjemand anderes mal passiert irgendeiner ber Person Die hat dann irgendwas ge zu sich selbst

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

Das ist ein 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

teilweise

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

Hat sich da in der Lizenz,

weil MySQL hatte ja so ein bisschen früher

eine etwas komische Lizenz.

Oder im Vergleich zu anderen,

also jedenfalls im Vergleich zu Postgres.

Postgres ist ja sehr liberal.

Postgres hat eigentlich ja nicht.

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

SnapBSD drauf, wegen der BSD-Lizenz.

Und dann, wenn so ein Datenbank

System wirklich brauchen, dann eine Postgres auch

wegen der Lizenz.

Auf der Apple Watch ist SQLite, wird auch

gern 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

überall drin sitzt.

Deswegen MySQL, MariaDB,

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öhnthopp 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, 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 du besser in Grafen abbilden kannst, bilde es in 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

genau, also da

ich finde

Postgres ist eigentlich immer ganz schön, oder sagen wir so,

weil es halt so ein bisschen ähnlich ist,

ich meine, ich mache ja so, 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,

was so Django für die Webwelt oder Ruby on Rails für die Webwelt ist.

Es ist zwar jetzt vielleicht nicht in allen Sachen spitze,

aber fast alles, was man so braucht, ist da schon mal drin

und man kann das einfach so verwenden.

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 Poskis 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 es völlig wurscht, ob du Poskis

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

und die Programmiersprache Python.

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

So PHP, was weiß ich.

Ja, Lamp.

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

und Python.

Ich erzähle dir auch erstmal nicht, dass es im 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, 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 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.

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

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 Mordfall, 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, das ist sehr interessant, das muss man halt auch schreiben dann,

denn 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, ja.

Aber das finde ich cool, ja.

Und ich habe noch ein zweites Story mal gemacht, das ist auch sehr schön, 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 einen...

Ich habe gerade bei den Psychologen, die Psychologenstatistik, 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, habe ich die Sterbestatistik draus gemacht.

und es war dann auch zwar makaber,

aber es war für die leichter

Nachfolge zu vollziehen, als irgendwas

BWL-lastiges.

Was passiert jetzt? Wie viele Menschen sterben

da jetzt von?

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

und Jochen unterhalten sich über die Programmiersprache Python

Tasse oder was man immer eine Prise, ich gebe mir alle Rezepte mit einer Prise drin, wo man das einheißt.

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 du lernen vielleicht besser, also wenn das nicht 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

füllen, wie man das mag. Genau, 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 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 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 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 nochmal 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...

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, Jochen, ist dir noch was eingefallen,

wie man das am besten lernen kann oder was du denkst?

Tja, ich weiß es nicht genau.

Ich habe vielleicht eine etwas pessimistische Ansicht dazu.

Ich glaube, ich weiß nicht, ob man das so trocken lernen kann.

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

und 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 sich einigermaßen nicht wohl fühlt, ist er derjenige,

der es richtig aus dem Schlaf dann...

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

Das ist natürlich ein guter Prof.

Also ich habe es 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, was ist Mengenlehre.

Mengenlehre war in der ersten Klasse,

und Jochen unterhalten sich über die Programmiersprache Python

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

Bucce Algebra, nee, Kombinatorik

ist es mit

A und B und nicht A

oder B und solche Geschichten.

Und ich sage immer, SQL

besteht ja fast nur aus Mengenlehre.

Entweder hast du

die Schnittmenge Join, ein einfacher Join

ist ja ein innerer Join, ist ja nichts anderes als

die Schnittmenge. Und OuterJoin

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

OuterJoin 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

durch den Faden verloren. Was war deine Frage?

Ja, ich wollte kurz, dass du über die Mengenlehre

sprichst, weil du gesagt hast, dass die Mengenlehre

drunter liegt. Ja, aber du hast vorher was

gefragt zur SQL.

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

und Jochen unterhalten sich über die Programmiersprache Python

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.

Zellen kam das 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. Das ist ja wie

Mengenlehre, so ungefähr.

Dass du nicht mehr nur

rote und blaue und bunte Plättchen hast,

und Dreiecke und Vierecke, sondern dann auch mal komplett mehrere 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.

Ich frage deswegen, weil vielleicht könnte man sich ja vorbereiten zu sowas, indem man nochmal sich so diese Basismengenlehre, wie du sagtest, mit den unterschiedlichen Schlittmengenkreisen vor Augen führt, um dann zu überlegen, wie das in SQL ausfällt.

so ein, jemand der sowas noch nie gesehen hat, der irgendwie einen komplexeren Outer-Droiden ein bisschen klatschen sieht, der ist vielleicht erstmal gefordert.

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.

ist sehr lustig, ist immer, dass das funktioniert bei MariaDB nicht so ohne weiteres, 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

wir haben aber dann ganz ganz

tolle andere Fähigkeiten

die ich nicht habe

aber das ist dann

naja

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 das einmal

verstanden hast, dann ist es auch nicht so schwer.

Vielleicht ist es jetzt Zeit, nochmal darauf einzugehen, also was

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

4., 5., 6., 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 sind.

Ich muss das 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...

Wenn in zwei Spalten irgendwo eine Adresse steht,

dann möchte ich die nicht dreimal drin haben, sondern

eine eigene Tabelle mit Adressen.

Ich hätte jetzt gesagt Stadt.

Ich hätte es noch weiter runter gebrauchen.

So Postleitzahl Stadt, das Klassische,

was so in der Tabelle ist. 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 Rekord, finde ich.

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 drinstehen und dann

hat Bielefeld vielleicht die ID 33615,

weil das die Posterzahl ist und

oder wonach man das auch immer bei

Städten wäre, die Posterzahl 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

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?

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.

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

und Jochen unterhalten sich über die Programmiersprache Python

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.

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,

mal die Einheit Teller oder was in diesem Küchenschrank ist.

und Jochen unterhalten sich über die Programmiersprache Python

und macht da halt zwei Tabellen.

Aber woher weiß ich denn jetzt, ob Wasser ein Weinglas, 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 versuchen.

Er möchte jetzt nur, nennen wir eine Automarke, nur Mercedes haben.

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

Du hast alles

in einer Tabelle.

und Jochen unterhalten sich über die Programmiersprache Python

es hat vielleicht noch die Reifentypen und so weiter

und die Reifengröße

und weiß weiß ich was

man da Baujahr und wie alt

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

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 Postgres genau das gleiche Problem kriegen wie mit MariaDB.

Der MySQL war es damals noch.

Und ich bin dann nach Hause gefahren und dann kriegte mein britischer Kollege

einen Anruf, der konnte die Konsulten 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.

Also 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 denn du das Und dann hat er mir das erz 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.

Hat er gehört, was sie vorher beraten hat

und hat gesagt, oh ja, ja.

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.

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

erwartbar. 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 zu fassen.

Ja, genau. Und das Normalisierende ist

einfach, du fasst das 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, fünfmal die Ärzte, kenn ich mehr Titel. Da steht dann 127 Mal, wer

weiß, wie viele Songs die Ärzte gemacht haben, da drin. 127 Mal die Ärzte und daneben steht dann,

und 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 erst schon 127 Zeilen, wo du die ersten 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 Songsammlung und dann hast du eine riesige Tabelle.

und Jochen unterhalten sich über die Programmiersprache Python

haben die halt so, was weiß ich,

die Ärzte ist vielleicht

Nummer 1 und dann steht in

deiner Songtabelle 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 oder sowas in der Richtung.

Also hast du danach die Nummer

und du kannst danach gucken, wenn du dann in der Tabelle

bist, okay, interpretest Nummer,

was hatte ich vorhin, 3 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.

Und die 3 sind von Sepultura, irgendeine Metalband.

Ja, egal. Nur,

dass du dann halt nur noch über die Zahlen

das machst. Und 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 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, so eine 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 in der Zwischentabelle

nur noch 1 1 drin, Album 1,

Interpret 1.

Dann kannst du das so zusammenfügen.

Siehst du halt,

ein bisschen auseinander und dann hast du halt nur noch die

Tabelle mit dem Titel, wo dann draufsteht

Album 1, Band 1,

also 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 hättest, wäre das

doppelt, aber das macht man schon, dann

das Deonomie sieht 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

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

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

und Jochen unterhalten sich über die Programmiersprache Python

und Jochen unterhalten sich über die Programmiersprache Python

Ich sag's dir, den Datensatz hast du den 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 sie dann ID,

dass so eine Spalte davor sitzt, wo du dann eine Kennung

rein hast und dann hast du dann

Nummer 1 ist Klaus Mayer, Nummer 2 ist

Klaus Mayer, 3 ist Klaus Mayer, 4 ist Klaus Mayer,

5 ist Klaus Mayer und dann kannst du dann sagen, delete alle,

wo Name Klaus Mayer

ist oder alle mit ID 2

bis 4, dann kannst du ja auch so machen

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

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

und wenn man dann davon weggeht, dann

spreit 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

bei irgendeinem neuen Problem oder so

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.

tatsächlich auf. 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 den Körper. 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 Musikgub alles an

Informationen in dieser Datenbank speichern.

Also wirklich so als

reines Sammelsurium, das ist natürlich

für andere Firmenprogrammierste das so,

und muss das erstmal aus den ganzen

Besprechungen raushaben, was brauchen die überhaupt

alles in der Datenbank, dann muss

man noch gucken, meistens führt die Firma mit,

was ist überhaupt erlaubt, abzuspeichern.

Gibt es ja auch sowas,

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

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

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.

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

Ja, ja, und dann deswegen ist so ein Nick ändern

bei so Spielen häufiger

mal so ein Problem gewesen.

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

Das ging relativ schnell,

es war ein guter Server, so viele Mitarbeiter

waren das nicht, aber dann so, ja,

die Stellplatte 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 ja eine Hitze, die

Differenz ja gar nicht gebraucht, aber ich fand

das damals sinnvoll, sie mit abzuschleichen und ich

rate das Hauptbandbestimmungen jeden

Style-Mit zu machen.

Doppelt hält besser dann, ja?

Ne, das ist auch teilweise wie du es in der Anwendung

brauchst. Wenn du immer

Differenz brauchst, dann brauchst du auch nur

die Differenz abfragen und musst nicht immer

Start- und Stopp abfragen später in der Anwendung.

zu machen. 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 Zukunft, was weiß ich, was mit berücksichtigen.

Deswegen hast du auch ganz viel in den Tabellen,

fast jeden Abteil noch

last updated und so

weiter mit in jeder Spalte.

Update 3, update...

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.

und wenn du jetzt ganz normal so eine Verkaufstabelle machst, dann hast du ja auch bei Preisen häufig,

wie wenn du einen Preis änderst, solltest du ja den alten Preis ja auch nochmal irgendwo...

Ja, schon praktisch, dann kann man dann 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 allen Rechnungen solche Geschichten.

Ich habe zu welchen Plätzen gekauft worden.

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

und 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 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, weil bei Mitarbeitern,

also bei sowas nimmt man meistens auch die Kennung.

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

Ich weiß nicht, ob Autos jetzt

Kfz-Zeichen unbedingt sinnvoll ist,

als Kennung zu nehmen, aber

es gibt halt so Schlüsse, 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?

Ja, nee, das ist schon sehr sinnvoll,

wenn das so eine ganze Zahl ist.

irgendwie. 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 ist halt so eine Frage. Das wäre eine interessante Frage.

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

Dann können wir ja vielleicht den Hash nehmen von dem Content.

Ich nehme gerne auch den Unix-Timestamp.

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, dann will man ja, dass sie eindeutig sind, hat aber keine zentrale Datenbank möglicherweise.

Es gibt halt diese Sache bei Postgres, bei MariaDB und so weiter, sogar im Standard gibt es den Datentypisch 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ählt es 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, 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 Wartelnack, 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, wie 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 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.

Das ist natürlich, wenn du dann so

einen Support am Telefon nennst, nennen sie mir mal ihre

Kunden-ID und dann fängt der da an,

Unix-Timestamps zu lesen.

Gut, du erkennst es als

Laie nicht als Timestamp?

Also da muss dir schon freak zu sein, dass du rastet, dass es ein Timestamp ist, von wegen Eindeutigkeit und schwer zu raten, aber es ist halt auch eindeutig, dass du dann irgendwie so in derselben Sekunde mehrere Kunden anlegst, das ist dann doch schon schwierig.

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-Postleitzahl eingegeben oder sowas.

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

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

Ja, also in Maler-Adventure 6 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, das ist einfach, weil ich muss ja erstmal, also ich nehme die Daten entgegen, also die Software, jetzt in eurem Fall Python, in Python geschrieben, die nimmt die Daten entgegen, so, jetzt nimmt sie die Daten so wie sie sind und schmeißt sie in die Datenbank, die Datenbank, äh, kann ich nicht einfügen, falscher Datentyp oder was auch immer, gibt dann, erstmal habt ihr eine Verbindung drauf gemacht, die sind bei Postgres relativ teuer, da rein, die gibt es dann zurück, kann ich nicht,

ihr kriegt den Fehler, behandelt den Fehler

wieder in Python.

Das ist doch dann sinnvoller bei sowas wie Postleitzahlen

das gleiche in Python zu prüfen.

Oder auch beim Geschlecht oder sowas.

Das Problem ist halt die Frage, ob ich jetzt wirklich alle

Ausnahmen irgendwie abfangen kann, die ich irgendwie ausdenken kann

oder es halt alles runterbreche

oder ob ich sage, ich mache da einfach ein Textfeld draus und es ist mir egal

und dann ist halt dann die Eigentätigkeit weg.

Was ich bei Postleitzahlen machen würde, die gibt es ja

als CSV, die würde ich einmal importieren

und dann würde ich mir die als Liste, dann kann er die auswählen.

Also es gibt, ja, okay, TriSuite, ja, gut,

aber

Ja

Ja, aber

Also ich meine, wenn das

Oder die Stadt anfangen

einzugeben und dann zeichnet der automatisch

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

aus einer Datenbank-Sicht 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

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

In Mannheim.

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

Also dann, wenn man sich mit Leuten unterhält, 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.

und Jochen unterhalten sich über die Programmiersprache Python

zu importieren.

Für Deutschland ja.

Hast du natürlich, wenn du international bist,

dann auch wieder.

Aber ich sag mal so, Straßen, Mannheim hat ja die

Quadrate T633, habe ich mal drin

gewohnt, glaube ich.

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

Wofür willst du das unbedingt in das Postleitzahlen?

Warum willst du da unbedingt irgendwas reintun,

was keine Postleitzahlen ist?

Weil ich die Adresse anlegen muss, um eine Bestellung anlegen zu können.

zu finden oder sowas. Ja, aber dann legt das doch, tu doch die Adresse

in das Textfeld. Ja, genau.

Dann kannst du ja versuchen,

eine Postleitzahl zu extrahieren oder so.

Ja, oder die Postleitzahl kommt direkt ins Textfeld.

Die Frage ist ja, woher

brauchst du diese Adresse? Genau.

Ja, also die Frage,

was halt noch schwieriger wird hinterher, ist halt Filtern

von Adressen. Also 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.

Dann nehme ich halt das Textfeld, dann kommt das halt auch an.

Aber wenn ich jetzt dann hinterher in die Analyse hingehen will,

in welchem Postleitzahlengebiet habe ich denn jetzt wie viel geliefert

beispielsweise, dann ist halt dann das Problem, dass die Textwelle

halt nicht mehr angezeigt wird.

Ja, aber dann ist halt die Frage, wie wichtig ist es,

bis auf die letzte Adresse stimmt und dann...

Genau, dann muss ich mir halt dann halt die Filter überlegen,

wie ich das dann wieder rausnehme.

Dann ist auch die Frage, ob du diese Analyse überhaupt fahren darfst

oder ob das gegen die Datenschutzrichtlinien verpflichtet ist.

Na gut, aber das ist ja ein anderes Problem.

Naja.

Also im Zweifel hat man ja berechtigte Interessen und dafür eine jeweilige

Datenschutzvereinbarung.

Ja, noch nicht.

Ja, das ja.

Aber,

ich habe die hier gleich aufgegessen.

Das ist ja lecker.

Nein, aber das ist so dieses,

nee, aber tatsächlich,

ich habe das auch schon mehrfach,

ich war dann einmal faul, ich habe dann mal angeguckt,

was passt denn auf einen Briefkopf,

ich glaube, du hast sechs Zeilen, hast du fünf?

Also ein normaler Briefkopf hat immer fünf,

oder da habe ich einmal,

wie heißt die?

Adresse 1, Adresse 2 oder ADR

1, 2, 3, 4, 5, 6, weil

mir ist das 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.

sofort. Bei Rechnungsadressen,

ja.

Ja, ich glaube, ihr redet nicht.

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 wollen. 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 Verbindungen oder über NoSQL

vs. SQL.

Und am Ende wollen wir nochmal

Maria gegen Postgres.

Okay.

Das würde ich auch schon.

Was wolltest du zu Transaktionen

müssen. Vielleicht erstmal, was ist das überhaupt? Also ich muss ja

davon ausgehen. Also eine Transaktion ist, der Dominik möchte

dem Jochen 100 Euro überreisen.

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.

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

Das wäre nicht gut.

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

So heißt der Befehl.

Wenn jetzt zwischendurch das Datenbanksystem abfällt,

und Jochen unterhalten sich über die Programmiersprache Python

jedes schreibende Zugriff, also jeder, ne, ne, ne, 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 in C, die Programmiersprache war eigentlich egal, aber du musstest immer ein Commit hinten dran werfen.

Du musst immer einfach mal Insert sagen und dann darunter Commit.

Mittlerweile machen die Datenbanksysteme alle Autocommit.

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

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

Aber es wird automatisch da hinten dran gefeuert, dass du das nicht mehr machen musst,

dass du da immer noch ein Commit einzeln hinterher machst.

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 Schreibungen und Transaktionen

und du sagst am Ende Commit

das wäre jetzt das mit dem

Kontoüberweis. Also das würde man zum Beispiel machen

in der Businesslogik von so einer Applikation

wo man zwischendurch noch andere Dinge abfragen muss

wo man Verbindungen aufbauen muss, wo man nicht weiß, ob die klappen

oder so

Ja, also bei allem

wo du mehrere Schritte hast und die halt entweder

alle funktionieren sollen oder keine

Genau, also das mit der Bank ist immer so

das macht, die Banken funktionieren natürlich

noch viel komplexer, aber das ist immer so ein schönes

Beispiel, weil das ist so schön

anschaulich.

Genau, und

Postgres und MariaDB haben aber eine

Abkürzung für StartTransaction, das ist

Beginn, also da kann man auch Beginn sagen,

statt StartTransaction, 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 Jahr

oder dass du wirklich so

entweder alles oder nichts.

Das ist im Grunde.

Dann macht man erst mal so ein Letter und dann muss man die einzelnen Transaktionen

dann kommitten 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

Postleitzahlen Deutschlands importieren.

Ja, aus dem CSV,

okay, das ist eh nur eine Transaktion,

aber du würdest das mit einem Insert-Statement machen.

Dann möchtest du auch entweder alle drin haben

oder keine.

Du willst nicht irgendwo, dass nach der Hälfte

irgendwie, dann hast du die halben Postleitzahlen drin

und die andere Hälfte nicht. Du würdest

auch mit einer Transaktion machen,

wie gesagt, wenn du das CSV hochlädst,

ist es nur eine, aber

du könntest das auch anders lösen. Das war jetzt zum Beispiel

was mir einfällt. Also es gibt da aber

durchaus ganz viele, kriegt da wahrscheinlich

jetzt ganz viele Zuschriften, was da die

Leute als Beispiel schon haben für Transaktionen.

Aber das ist so das

Transaktion und das wird mitgelockt.

Tatsächlich, das Transaktionslog ist ja das wichtigste

überhaupt bei Postgres,

bei Datenmarken. 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 wiederhergestellt werden.

Das ist in den Backups so wichtig.

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

Ja, das Transaktionslog schreibt halt immer auf die Platte, das ist das Wichtige daran.

Es sei denn, da muss man immer aufpassen.

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

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, also 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 Ich brauche bei VMs dann sagt die VM es ist fest auf der Platte es ist aber erst ein Cache des Hoses oder so Das ist auch was da habe ich bei VMs 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 RAID-Controller mit Batterien drauf.

Ja, natürlich.

Ansonsten, ich glaube, Postgres-Verbände, irgendwie F-Sync und F-Sync kann man auch irgendwie sagen,

so sag mir, werde erst fertig, wenn du es wirklich, wirklich auf der Platte geschrieben hast.

Das ist halt, das macht es langsamer,

aber ja. Nein, F-Sync ist

das, was wir immer in den Opus

gibt, weil man sagen stellt, das ausschaut, 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 hochladen. F-Sync sollte man nie

abschalten. Es gibt Synchronos 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 ACK, das OK zurückgeben,

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 ACK, das Acknowledgement oder das OK zurück.

Wenn wirklich das von der Transaktion, wenn das System sagt,

und Jochen unterhalten sich über die Programmiersprache Python

und irgendwie so ähnlich.

Ist eine ganz lange Variable bei

MariaDB.

Ich weiß immer nicht, wie sie heißt.

Dann gab mir mein Kollege, ein ehemaliger

Kollege, einen Tipp. Er sagte, ich weiß auch nicht,

wie sie heißt, aber es ist die längste Variable,

die es gibt.

MariaDB hat wahnsinnig viele Servervariablen.

Es war wirklich die längste, aber ich glaube, es gibt

mittlerweile eine längere.

Sie ist relativ sprechend auch.

Flash

Transaction Commit, irgendwie so ähnlich

heißt sie. Genau.

Und das ist das. Aber F-Sync

sollte man eigentlich nicht abstellen. Wie gesagt,

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

das fängt 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 haben. Also je nachdem,

für manche Sachen reicht auch eventuell.

Also Datenbanken sollten Asset-konform sein,

das heißt Atoma, 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 Isolationsmetall

Repeat Committed

oder Repeater, Repeat ist sowieso Standard

da muss man eigentlich nicht nochmal dran

es sei denn man ist irgendwo

im tiefen universitären Bereich

und will das auf serializable stellen

da kann ich aber auch sagen, die meisten Bugs

haben alle Datenbanksysteme, haben ein Riesenproblem

mit diesem Isolationsmetall

können wir nochmal drum machen