#216 Konsistenz und Isolation: von Write Skew bis Dirty Reads

[SPEAKER_01]: Episode 216 vom Engineering Cures Podcast. [SPEAKER_01]: Wolfgang, einer der Co-Hosts von diesem Podcast, hat lange Zeit in der Forschung Gruppe für Datenbagnung und Information-Systeme an der Uni-Innsurg verbracht. [SPEAKER_01]: In dieser Episode zappt mir sein Datenbagnungswissen an und sprechen über Konsistenzmodelle. [SPEAKER_01]: Also darüber, warum deine Daten manchmal ein bisschen, nah ja. [SPEAKER_01]: Unärlich sind.

[SPEAKER_01]: Von Dirty Reads über Right Skills bis Phantom Reads, wir klären, was das für Phänomenes sind, warum die Arbeit mit Transaktionen nicht immer ganz so einfach ist, welche Esulationslevel eine Datenmack eigentlich zur Verfügung stellt und warum du dir doch mehr Gedanken darüber machen solltest als ihr eigentlich liebest. [SPEAKER_01]: Klingt kompliziert? [SPEAKER_01]: Keine Sorge, wir bringen in den nächsten schon eine etwas Ordnung ins Chaos der Buswods.

[SPEAKER_01]: Also, Kopfhörer auf Transaktion starten und kommet nicht vergessen. [SPEAKER_01]: Los geht's!

[SPEAKER_01]: ein bisschen trocken und in vielen Blockposts sind für dieses Thema auch echt viele Zeichnungen mit ganz vielen Feilen und so deswegen haben wir uns mal den besonderen Herausforderungen gestellt und sagen okay wir versuchen dieses komplexe Thema doch mal auf die audio ohne Liespur zu kriegen und falls du gedacht hast wo auch gestern schon wieder drei wein zu viel getrunken [SPEAKER_01]: Man schädelbar ist auch ein bisschen der Thema, weil du es dritt sagst, oder?

[SPEAKER_01]: Genau, weiß ich nicht, ob genau dieses Thema das Thema ist, was du dir jetzt anhören willst. [SPEAKER_00]: Du hast irgendwie oft die schon über Transaktionen um da halten, habe ich bei einem Bier. [SPEAKER_00]: Es ist mein ganzes Leben. [SPEAKER_01]: Bei einem Bier denkt es zu ja auch, wo hast du öfter recht, aber wenn du am nächsten Tag merkst, dass du vielleicht zu viele Bier hat, weiß ich nicht, ob ich eine Podcaste-Person-Tema-Transaktionen und Co-Hörn möchte.

[SPEAKER_01]: Deswegen habe ich mir ganz klar gedacht, [SPEAKER_01]: Bevor wir hier mit dem Hakenkram kommen, deswegen habe ich natürlich mal wieder drei Flachpitze ausgesucht und Achtung nach dieser Episode, habe ich zum Ende noch zwei Flachpitze die man aber erst versteht, wenn man die Episode gehört hat. [SPEAKER_01]: Also, fang ich mal an. [SPEAKER_01]: Ich bin gespannt, ihr gehen mal einen Kaffee holen da in der Zwischenzeit.

[SPEAKER_01]: Ich wollte meiner Datenbank ein Geheimnis erzählen, aber sie hat sofort repliziert. [SPEAKER_01]: Okay, Wolfgang Grimmeskarr. [SPEAKER_00]: Es ist ganz nicht schlecht. [SPEAKER_00]: Es ist geil, so schlecht. [SPEAKER_01]: Okay, fangen wir mal an. [SPEAKER_01]: Weiter geht's. [SPEAKER_01]: Hast du dir nicht immer aus ein englischen Übersetzt, oder? [SPEAKER_01]: Noch nicht, das war jetzt eine Che-GPD-Edit-Best.

[SPEAKER_01]: Was sagt eine Event-Schul-Konsistent-Datenbank nach einem Streit? [SPEAKER_01]: Wir gleichen uns schon irgendwann wieder an. [SPEAKER_01]: den fand ich ganz gut. [SPEAKER_01]: Und jetzt kommt für mich wirklich der Krächer zwei Datenbankentreffend sich. [SPEAKER_01]: Eine sagt, ich bin konsistent, die andere gibt mir ein paar Sekunden.

[SPEAKER_01]: Aber wir sind schon beim Thema Konsistenz Replication und so weiter, deswegen Dr. Halb Professor Wolfgang Gassler erklär mir doch mal bitte was das Wort Konsistenz eigentlich bedeutung und Lachtung. [SPEAKER_01]: Ich weiß nicht warum, als du mir dieses Thema Gepitzt hast und als du mir dieses Dokument, dieses Vorbereitungsdokument des Schicktast damit ich mal gegenlese [SPEAKER_00]: Du hast es klar, wir mal in irgendeiner Episode des Falschgesagt.

[SPEAKER_01]: Ihr habt es schon mal rausgeschnitten, wenn ihr das richtigen Kopf habt. [SPEAKER_01]: Also, fangen wir an, springen direkt rein. [SPEAKER_01]: Was bedeutet eigentlich Konsistenz? [SPEAKER_01]: Ist das der AGG-Gatszustand meines Puddings oder was ist es? [SPEAKER_00]: Ja, es kommt schon an, mal grundsätzlich darauf an, in was für im Umfeld man sich bewegt und die Konsistenz definieren will.

[SPEAKER_00]: Beziehungsweise auch die inkonsistenz, denn inkonsistenz nicht inkontinent, ist es nicht auch ein Verschreiber, der man sehr gerne hat. [SPEAKER_01]: Das Problem ist, die grammatikalische Korrektur von deinem Google Docs kann ja auch... Also, die macht ja nichts, weil es könnte auch korrekt sein, dieses inkonsistenz inkontinent. [SPEAKER_00]: Ja, also es ist, mein Sietschaft der Audio-Spur ist sehr, sehr schwierig.

[SPEAKER_00]: Aber es gibt grundsätzlich mal Datenbanken, wo man das eigentlich immer so hört, die Konsistenzmodelle und eventuell Konsistenz hier ist schon gesagt, war er mal dann da große Schlagwort bei der No.

[SPEAKER_00]: Es koelt Datenbanken, aber es betrifft eigentlich nicht nur Datenbanken, sondern ganz allgemein Barallelles Systeme, also ein System, wo Barallelles mehrere User drauf zugreifen und in Verteilten Systemen, also wo mehrere Notes, [SPEAKER_00]: miteinander sprechen und die Daten verteilen, dort gibt es natürlich diese Konsistenzmodelle und die Konsistenz an sich genauso.

[SPEAKER_00]: Es ist kommt darauf an, was für ein Bereich man sich bewegt und da unterscheidet sich dann der Begriff vielleicht.

[SPEAKER_00]: Wenn wir jetzt mal beim einfachsten starten Datenbanken, dann bedeutet das im Datenbank sehen auch das [SPEAKER_00]: C in S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S [SPEAKER_00]: Oder in den cooleren Datenbanken, meist Kölk an das leider immer noch nicht, kann man so checkkrederien definieren.

[SPEAKER_00]: Also, gewisse Formaten muss immer kühltig sein oder es muss gewisse Einträge in der zweiten Tabelle geben, beispielsweise wenn man eine Rechnung schreibt, dann braucht man den Kunden, aber man braucht vielleicht auch irgendwelche Verträge, die schon unterschrieben worden sind. [SPEAKER_00]: Dann kann man mit so checkklauseln überprüfen, ist da ein Vertrags [SPEAKER_00]: A und B und C schon unter Schrieben und erst dann darf ich eine Rechnung stellen zum Beispiel.

[SPEAKER_00]: Also das wird dort alles drin in abgebildet und jedes Mal, wenn ihr auf die Datenbank trafblicke ist das Konzistent und ich kann keinen Fehler, keinen logischen Fehler in meinen Daten finden. [SPEAKER_01]: Meine Zeitfrage, damals sind meinem Studium, habe ich gelernt, wenn es geht, verlagere so viel logik wie möglich in die Datenbank.

[SPEAKER_01]: Irgendwann später in der Praxis habe ich gemerkt, vielleicht ist das gar nicht so geil, mit der es kommtst du an und sagst, solche Check-Constrains kann man machen und so weiter und so fort. [SPEAKER_01]: Und da frag ich mich gerade, ist es überhaupt klubt diese Check-Constrains in der Datenbank zu haben oder sollte man nicht lieber im Application Code haben. [SPEAKER_01]: Wies er deine Meinung?

[SPEAKER_01]: Oder sind wir gerade auf Applicationen, die als PS-Guell in eine Oracle-Datenwag laufen oder in einer MS-Guell oder ähnliches? [SPEAKER_01]: Das ist ja noch schlimmer. [SPEAKER_00]: Aber ich bin da auch ein bisschen zwiegespalten, ab was für ein Zeitpunkt man eher in die Business Logik gehen sollte und wie lange man in der Datenbank bleiben kann. [SPEAKER_00]: Man könnte dann ja auch Trigger oder solche Dinge noch definieren in der Datenbank.

[SPEAKER_00]: Meine Herangehensweise ist eigentlich immer [SPEAKER_00]: Wenn die Datenbank gewisse Jacks anbietet und meine Jacks sehr grundlegend sind und die sehr einfach abbildbar sind, das heißt, wenn ihr jetzt eine Business Logik habt, die sehr starre ist und sich selten ändert, die würde in der Datenbank ablegen.

[SPEAKER_00]: Wenn ihr jetzt natürlich Business Logik habt, die sich so irgendwie im Wochendakt ändert, die würde auf jeden Fall in den Code reinsetzen. [SPEAKER_00]: Also wenn da gewisse Verträge sich ändern, die die Kunden unterschreiben müssen und es gibt [SPEAKER_00]: Hundert der Arten von Kunden, das würde dann irgendwie anders abbilden.

[SPEAKER_00]: Aber wenn es darum geht, ein Format zu checken, zum Beispiel, das etwas immer eine gewisse Ragex zum Beispiel erfüllt oder ganz klassisch, dass keine Nahlwerte drin sind. [SPEAKER_00]: Diese ganzen Dinge, die wir die natürlich schon auf jeden Fall in der Datenbank haben, wollen weil, wenn du im Kotenproblem hast, wenn du ein Back hast, dann hast du das immer noch in der Datenbank und die Datenbank bringt dir dann Fehler zurück.

[SPEAKER_00]: Also diese Dinge machen schon absolut zehn in der Datenbank. [SPEAKER_00]: Sobald es irgendwie ein Statement ist, ein if Statement oder sowas, was wir über fünf Zahlen geht, würde eher in die klassische Businessloggik vom Code von der Ablication, eigentlich überschieben.

[SPEAKER_01]: Die Herausforderung, die ich immer entdecke, wenn du Code in die Datenbank verschieben, sie sie sichtbarkeit des Codes, denn als Softwareentwickler und Softwareentwicklerin programmierst du da was und machst du, wenn Inzert Statement oder was es Inter-Inzert Statement geht dann irgendeiner Logik in der Datenbanklos und dies halt nicht sichtbar für dich

[SPEAKER_00]: Ein anderer Punkt, wo es aber auch ganz wichtig ist, ist, wenn du unterschiedliche Applikationen hast, die auf dieselbe Datenbank zu greifen. [SPEAKER_00]: Auf dieselben Daten. [SPEAKER_00]: Weil dann ist natürlich die Datenbank deine zentrale Schnittstelle und die prüftern, ob die Daten korrekt sind. [SPEAKER_00]: Also kommt der doch oft vor, dass irgendwie voll im Gewachsenen System in großen Firmen greifen dann acht Applikationen auf dieselben Daten zu auf dieselben Dabellen.

[SPEAKER_00]: Und dann ist es ein dick schon gut, wenn du auf der Dabellenseite diese Jackson und die Constrains regeln in Varianten, [SPEAKER_00]: Ja, aber Leute, die diesen Podcasts ja schon länger hören, die machen das ja nicht, also von daher. [SPEAKER_01]: Wie war das mit Legacy verdientes Geld? [SPEAKER_01]: Ja, irgendwann muss die Miete zahlen. [SPEAKER_01]: Lassen Sie uns zurück zum Begriff Konsistenz. [SPEAKER_01]: Du hast mir den Begriff jetzt im Kontext von Datenbanken erklärt.

[SPEAKER_01]: Wie sieht's denn bei Verteilt System aus, zum Beispiel? [SPEAKER_00]: Bei Verteiltensystemen oder man kann eine Verteiltedaten Banken jetzt als Beispiel natürlich nehmen. [SPEAKER_00]: Aber es gilt ganz allgemein. [SPEAKER_00]: Ich habe mehrere Knoten mehr Reserver, die ihn und einer Form miteinander kommunizieren kann im selben Date das Ende sein kann, weltweit Verteilt sein. [SPEAKER_00]: Gibt es natürlich alle Varianten?

[SPEAKER_00]: Da spricht man eigentlich von Konsistenz immer davon, dass die verschiedenen Knoten in meinem Verteiltensystem den gleichen Zustand haben. [SPEAKER_00]: Das heißt, die sind untereinander Konzistent. [SPEAKER_00]: Natürlich die Datenbanken in sich sollten natürlich auch Konzistent sein. [SPEAKER_00]: Und wenn diese Check-Kräderien natürlich gecheckt werden in der Datenbank sollte das Stimmen.

[SPEAKER_00]: Aber da spricht man bei Konzistent immer davon, dass alle Knoten dieselben Daten haben und wenn du jetzt auf... [SPEAKER_00]: Dann im ersten Server eine Selectabfrage start ist ein solches du die selben. [SPEAKER_00]: Ergeben es hier bekommen, wie wenn du auf einen anderen Server kommst. [SPEAKER_00]: Wenn du auf einen amerikanischen Server kommst, bekommst du die selben Kunden zurückgeliefert, wie wenn du ihn deutschland auf deine Datenbank zu greifst und die Kunden abfrext.

[SPEAKER_00]: Und da kommt dann auch dieses Eventual-Konsistin-Siehen-Spiel, dass man bei NoSQL und ganz oft auch ganz allgemein bei verdeilten Datenbank natürlich hat, dass man sagt, die Knoten haben nicht zu jeder Zeitengleichen stand, sondern irgendwann mal in der Zukunft. [SPEAKER_00]: Also von der im Frachwitz. [SPEAKER_00]: Gibt mir mal eine Zeit, wie sie dann zum Grund bin, das ist eventuell Konsistenzie.

[SPEAKER_00]: Und man kann sich das vorstellen, wenn man jetzt zehn Server über die Welt verteilt hat, einer Stelle in Amerika, einer in Asien, einer in Deutschland, dann ist es natürlich schwierig zu garantieren, dass zu jedem Zeitpunkt egal wann alle dieselben Daten haben. [SPEAKER_00]: Das kann man natürlich schon garantieren, aber dann dauert natürlich jedes Mal, wenn die irgendwelche Daten ändert, da hat es sehr lange, weil alle Knoten abgeglichen werden müssen.

[SPEAKER_00]: Und erst wenn alle Knoten gesagt haben, ja, ich habe geschrieben, bei mir sind die Daten, dann muss man wieder ein Händschäck machen, wenn nach bis alle Daten überall verfügbar sind und auch sichtbar gemacht werden. [SPEAKER_00]: Und das ist natürlich super kompliziert und darum macht man das bei NoSQL Daten eben seltener. [SPEAKER_00]: Oder ob ganz allgemein, also, noSQL dem Sinne jetzt von verteilten Datenbank.

[SPEAKER_01]: Inzwischen kommen wir wieder die Blockposts hoch, dass es nur als Gölde in Begriff gar nicht gibt oder was er hat. [SPEAKER_01]: Habt ihr da abgeflachtes und so weiter? [SPEAKER_00]: Es haben wir ja gleich in unserer Episode auch damals schon erwähnt, dass nur als Kuellier durch aus jetzt im Abflachen ist und es hat vielleicht auch so negativen Beigeschmack, irgendwie dieses No.

[SPEAKER_00]: S. Kuell, dass das so eine dumme Datenbank ist und die Klebtarum, auch wenn so eine Dokument-based database ist, nennt man sie lieber Dokument-Base oder irgendwie weltweit vertaltet Dokument-Base database an Statt-No. [SPEAKER_00]: S. Kuell zu sagen. [SPEAKER_00]: Hab ich mir gerade nachgeschaut, unsere NoSQL Episode ist doch schon eine Zeit her, war die Episode 22. [SPEAKER_00]: Gut all the times. [SPEAKER_01]: Und dann hast du Initial von Parallel in Systemen gesprochen.

[SPEAKER_01]: Was sind Parallel dieses Thema und wo es der Unterschied zu verteilt Systemen? [SPEAKER_01]: Und warum sollte da Konsistenz anders behandelt werden? [SPEAKER_01]: Beziehungsweise, warum bedeutet Konsistenz, was per Parallel in Systemen an der? [SPEAKER_00]: Also ich habe die Datenbank schon erklärt, ich würde sagen, Datenbanken sind eine Untergruppe von parallelen Systemen.

[SPEAKER_00]: Also paralleles System heißt einfach, dass ich mehrere User habe, ich habe diese ganze Problematik mit Race Conditions mit paralleler Ausführung, die Leute lesen, schreiben, parallel in ihren Connections auf den selben Datenbestand und Datenbank ist dann natürlich eine spezielle Form dafür, aber ich kann natürlich auch ein [SPEAKER_00]: System haben was einfach in den Hauptspeichern, was reinschreibt oder eine Applikation. [SPEAKER_00]: Da haben wir natürlich das selber Problem.

[SPEAKER_00]: Grundsätzlich, wenn die Super-Demitatenarbeit und die Race-Konditions kennt, war schon nicht ja jeder aus dem Programmieralltag. [SPEAKER_00]: Das ist diese Probleme auch gibt.

[SPEAKER_00]: Und diese Isolationsmodelle, über die wir auch sprechen werden, die Gäldener durch die Datenbanken, aber auch ganz allgemein, wenn ich programmiere, Nebenleuchtigkeit, meinem System, muss ich mir natürlich auch Gedanken machen, [SPEAKER_00]: Kann ich meine unterschiedlichen Güser isolieren, wann zeige ich welche Daten an, also die Problematik habe ich da genauso. [SPEAKER_01]: Herr Professor, hast du mal ein paar Praktische Beispiele für mich?

[SPEAKER_01]: Du bist ja wieder in deinem Uni-Modell hier, in den du vorne am Pult stehst und wieder irgendwelche Fachberift auf den Leitz runtergeratt hast. [SPEAKER_01]: Gibt mir mal real weltbeispiele von Konsensbeziehungsweise in Konsens, in Packerbütersystem. [SPEAKER_00]: Also bei parallelen Systemen, wenn man mehrere User die auf die selbe Datenbank zum Beispiel zugreifen, dann sind das üblicherweise diese Beispiele, wo mehrere User auf den selben Daten operieren.

[SPEAKER_00]: Wenn es die User komplett getrennt sind von einer anderen, wenn jetzt die Kneanung jeder spielt, ein Online-Game für sich im Single Mode, dann spielt jeder für sich die Daten mein abgelegtes komplett egal, [SPEAKER_00]: am server sind ist das komplett egal natürlich, weil die nicht auf die selben Daten zugreifen. [SPEAKER_00]: Problematisch wird es erst, wenn man wirklich die selben Daten in irgendeiner Form braucht oder verwendet.

[SPEAKER_00]: Ganz klassisch bei barrieren Systemen ist natürlich die Bank, weil wenn man einfach Geld transferiert von einem Konto aufs andere, dann muss das natürlich einfach immer consistent. [SPEAKER_00]: sein und es darf nicht sein, dass wenn die bei Konto A da sind Euro abbuche und bei Konto B da sind Euro dazubuche, dass die da sind Euro irgendwo verloren gehen oder dass der Konto stand nicht stimmt.

[SPEAKER_00]: Das ist bei Transaktionen sowieso immer das klassische System, aber es gibt natürlich auch ganz simple Beispiele, die sind jetzt vielleicht nicht zu kritisch.

[SPEAKER_00]: Aber wenn natürlich in einem Online-Shop irgendwo ein Lagerbestand mit dabei ist, ich bestelle jetzt etwas See, das ist Lagernd und in der Zwischenzeit hat dabei eine andere Transaktion ist ganze bestellt und schnappt mir sozusagen meine Snickers unter unserem Aschweck, dann habe natürlich ein Problem und die bin jetzt vielleicht nicht verliert keine Dausend Euro in dem Sinne wie bei einer Bank, wenn ich eine Transaktion mache, habe ich natürlich umzufriedene Kunden.

[SPEAKER_00]: Und das will man natürlich auch verhindern. [SPEAKER_00]: Ein Klassiker, wenn ich Taylor Swift-Tickets kaufen möchte. [SPEAKER_00]: dass die Disney-Kausunter im Aschweck gerissen werden? [SPEAKER_01]: Nee, die Tellers 5 tickets. [SPEAKER_01]: Du hast aber jetzt gerade schon wieder in deiner Unieerklärung mit ättlichen Fachbegriffe umlich geschmissen. [SPEAKER_01]: Transaktion, du hast von das Ziel in Esset gesprochen.

[SPEAKER_01]: Du hast von NoSQL gesprochen und von Eventuell Konsistenz. [SPEAKER_01]: Und ja.

[SPEAKER_01]: Wir haben zu allem bereits eine Episode gemacht, aber damit man dir jetzt gleich auch mal bei den Innovationsmodellen, die du uns gleich erklären willst, auch folgen kann, kannst du uns mal ganz kurz, dann fünf wie nun Crash kurz, in Datenbank Basics geben, was es eine Transaktion, was es es ist und so weiter und so fort, welche Sachen müssen wir jetzt wissen, um dir gleich folgt zu können? [SPEAKER_00]: Hast du schon mal mit einem Spielzeug Goda, mit einer Programmiersprache?

[SPEAKER_00]: Hast du das schon mal mit Meisskoll zum Beispiel gesprochen? [SPEAKER_00]: Hab ich. [SPEAKER_00]: Hast du da Autocomit eingeschalten oder abgescheult? [SPEAKER_00]: Ich habe auf Seien die Fohlz vertraut. [SPEAKER_00]: Deshalb habe ich jetzt auch mal gemacht, ich bin ja nicht zu der beiden.

[SPEAKER_00]: Programmierern muss man dazu sagen, aber wir verwenden ja auch hin und wieder in der einen oder andere Stelle beifend. [SPEAKER_00]: Und ich hatte das Erlebnis jetzt gerade kürzlich, dass wir hatten dann Beifendul, das hat immer nur gelesen aus der Datenbank. [SPEAKER_00]: Und alles Guck gegangen waren, als System und irgendwann hatte ich ein Insatz-Datement. [SPEAKER_00]: Ich bin gedacht, okay, ich mach jetzt ein Insatz-Datement, gar kein Problem.

[SPEAKER_00]: Es war so im Umfeld von Autentifikation mit Kies und so die Rotieren und ich habe da immer Kies verloren. [SPEAKER_00]: Während die so nen Kirodiert habe, in insatzstätement wurde abgefeiert, aber es ist in der Datenbank dann nie aufgedacht. [SPEAKER_00]: Ist mir übrigens dann erst bei im Produktivsystem so richtig aufgefallen, aber das war ein anderes Problem. [SPEAKER_00]: Und dann habe ich gemerkt, dass bei Beißen, beim MaiscoL client, Autokomit, nicht aktiviert ist.

[SPEAKER_00]: Bei allen anderen Programmiersprachen, mit denen ich üblich so arbeite, ist Autokomit aktiviert, bei Beißen nicht. [SPEAKER_00]: Was hat es jetzt zufolge? [SPEAKER_00]: Ihr habt nicht im Andere, das glaube ich auch mal erzählt, [SPEAKER_00]: Das heißt, sogar ich als Datenbankler habe dieses Problem darin beifend gehabt und zwar ist ein autokomit, ein automatisches Komit, nachdem man eine Anfrage an die Datenbank schickt und üblicherweise ist es eingeschalten.

[SPEAKER_00]: Das heißt, wenn in Insatz datement mache, dann wird mein Insatz datement an die Datenbank geschickt und wenn das fertig ist wird noch ein Komit nach gesendet quasi oder gleich mit gesendet, das sagt der Datenbank, [SPEAKER_00]: Dieses Insatz-Datement kommt jetzt nichts mehr danach, immer jetzt nicht noch fünf andere Insatz-Datements, die mit dem zu tun haben, sondern das war's jetzt, du kannst die Daten wirklich abspeichern.

[SPEAKER_00]: Das heißt, in der Datenbank haben wir eigentlich immer Transaktionen. [SPEAKER_00]: Auch wenn wir gar nicht damit arbeiten und die wenigsten arbeiten, ja, damit muss man dazu sagen, hat man zur Transaktionen nur wird halt automatisch im Ende im Kommit gefeiert. [SPEAKER_00]: Wenn man das Komit nicht mitzendet, was hier genau das, man schickt zwar inserztet, wenn es die Datenbank sagt, okay, inserztet, wenn das fein.

[SPEAKER_00]: Aber meld bitte mir, sobald du nichts mehr weitere Schicks, weil dann schreibe ich das wirklich auf die Platte eigentlich. [SPEAKER_00]: Und genau das hat bei mir gefällt. [SPEAKER_00]: Und darum sind die Daten nie, was es diert worden am Ende.

[SPEAKER_01]: Naja, im Normalfall sagt man ja auch am Anfang seines Statements irgendwie start transaction oder ähnliches und dann fährt man seines Statements und dann packt man in der erregeljahren komitinter ab und zu gibt man sogar noch an was bei einem on failure oder bei einem rollback passieren soll also wie der rollback aussieht, wenn man was speziell ist machen möchte, aber deswegen kann nicht schon verstehen, dass das Auto komittern vielleicht nicht an oder aus ist.

[SPEAKER_00]: Auf jeden Fall, was man wissen muss, ist, dass man eigentlich auch, wenn man nur eine Anfrage schickt, zeißene Selekt anfragen, eine Insatzanfrage eigentlich immer eine Transaktion macht. [SPEAKER_00]: Und eine Transaktion ist eigentlich dafür, dass man mehrere Statements zusammenkubiert.

[SPEAKER_00]: Das heißt, wenn jetzt wieder im Bankwesen bin und eine Transaktion, da heißt sie auch Transaktion durchführen, das heißt, hier über weiß Geld von meinem Konto A auf Konto B, dann will ich diese ganzen Statements, die da habe, wie macht er irgendwie ins Selekt, wie viel Gold zur Geschenk. [SPEAKER_00]: Reden nicht von Andes Konto, sondern von Konto Aankonto B. Also, wie viel Geld ist der am Konto? [SPEAKER_00]: Kann ich da überhaupt 300 Euro abziehen?

[SPEAKER_00]: Ist der genug am Konto verfügbar? [SPEAKER_00]: Was ist der für Kontostand? [SPEAKER_00]: Dann ließ ich in zweiten Kontostand, wo es Geld hinsenden will? [SPEAKER_00]: Was ist der oben an Geld? [SPEAKER_00]: Dann atiere das ganze und am Ende schreiben die neuen Kontostande. [SPEAKER_00]: Ganz easy. [SPEAKER_00]: Und das Back hit zusammen in der Transaktion. [SPEAKER_00]: Und die Datenbank garantiert mir dann eigentlich eben diesen Konsistenten zustand.

[SPEAKER_00]: irgendwie Geld transferieren sollten. [SPEAKER_00]: Zu selben Sekunde, Milisekunde, dann garantiert mir die Datenbank, dass jede Transaktion in sich Konsistent ist, durchläuft. [SPEAKER_00]: Und wenn ihr im Ende des Komitzeits und die Datenbank mehr Farms abgibt am Ende, dann weiß ich, dass das alles passt und der Kontostand in Ordnung ist.

[SPEAKER_00]: Und genau darf ich es Ihnen nicht diese Transaktionen, die in der Datenbank immer zu fügen stehen, aber ganz selten übrigens von Entwickler Ihnen auch verwendet wird. [SPEAKER_00]: Weil wenn Ihr jetzt die Frage wie viel Start Transactions hast zu in deinem Code üblicherweise. [SPEAKER_00]: Hast du sie überachst schon mal verwendet? [SPEAKER_01]: Ja, ja, ja, ja, ja, ja, ja. [SPEAKER_01]: Also ich hatte schon die Werse Applikation, da war das wirklich wichtig.

[SPEAKER_01]: Aber in vielen Applikationen spielt das bei mir keine große Rolle. [SPEAKER_00]: Man muss ja auch sagen, ich verwende es auch relativ selten. [SPEAKER_00]: Also, weil bei ganz vielen Dingen braucht man es ehrlich gesagt nicht. [SPEAKER_00]: Und dann ist es auch die Frage, will man das überhaupt diesen Aufwand in Kauf nehmen oder ist es einfach egal, wenn irgendwo einbaut, nicht ganz genau stimmt.

[SPEAKER_00]: Aber es kommt immer darauf an, in welchem Umfeld man unterwegs ist, natürlich. [SPEAKER_01]: Ich kann mir gut vorstellen, dass Leute, die bei Krankenkassen arbeiten. [SPEAKER_01]: Also, ich hoffe, dass Leute, die bei Krankenkassen arbeiten, sehr viel mit Starttransactions und Co-Arbeiten. [SPEAKER_01]: genauso wie in irgendwelchen Versicherungen und Co. [SPEAKER_01]: Falls du in einem solchen Feld arbeiten, so du tutst es nicht, lass es bitte mich niemals wissen.

[SPEAKER_00]: Danke. [SPEAKER_00]: Es wäre relativ einfach, das zu verwenden. [SPEAKER_00]: Also man braucht eine Transaktion starten und eine Transaktion beenden. [SPEAKER_00]: Der Rest wird von der Datenbank gemacht. [SPEAKER_00]: Damit die Datenbank des Überhaupt alles machen kann, gibt es eben diese Acid Properties, die man wahrscheinlich schon mal gehört hat, ist eine Datenbank Acid oder nicht.

[SPEAKER_00]: Mal allerrelationalen Datenbank sind üblicherweise Acid, also Atomarität, Konsistenz, Isolation und Dauerhaftigkeit. [SPEAKER_00]: Also das ist das RTE. [SPEAKER_00]: heißt dann nicht nichts anderes Atomarität heißt, es funktioniert eben alles oder gar nichts.

[SPEAKER_00]: Das heißt, wenn mein Geld überwiesen wird und es hat irgendwo ein Problem schlägt fehl, dann sollte es ganze wieder zurückgerollt werden und die sollte nicht irgendwie das Geld halb überwiesen haben oder auf einem falschen Konto, oder am einen Konto, wo es abgezogen am zweiten nicht, solche Dinge dürfen nicht passieren, also Atomarität entweder es funktioniert alles oder gar nichts.

[SPEAKER_00]: Konsistenz haben wir jetzt eh schon durch besprochen, das heißt, es muss immer alles konsistenz sein. [SPEAKER_00]: die isolation, die Abgrenzung, die haben wir auch schon ein bisschen zu besprochen, dass eben jede Transaktion in sich eigenständig ist und nicht von anderen beeinflusst werden kann. [SPEAKER_00]: Also, wenn zwischen drin noch jemand andere Geld überweist soll, ist nicht meine Geld Überweisungen in irgendeiner Form beeinflussen.

[SPEAKER_00]: Das heißt, wenn ich da irgendwo minus 300 [SPEAKER_00]: Abziehe von dem Kontostand und in der Zwischenzeit überweistere wir irgendwie Geld auf dieses Konto, dann soll dann nicht irgendwie in ungültiger Kontostand sein, dass der womöglich niedriger oder höher ist als eigentlich sein sollte.

[SPEAKER_00]: Also es muss wirklich die Transaktion immer isoliert angesehen werden und des D, die Dauerhaftigkeit [SPEAKER_00]: bedeutet eigentlich, wenn ich mein Commit-Zende bei dieser Transaktion ist, es garantiert gespeichert, egal ob der Stromausfeld, egal ob der Server zusammenbricht, egal ob 100.000 andere User auf der Datenbank sind. [SPEAKER_00]: Wenn ich das okay bekommen, ist es dauerhaft gespeichert, auch wenn ihr in der nächsten Millisekunden der Stromausfeld.

[SPEAKER_01]: Und nur zu globalen Einordnungen ist hier. [SPEAKER_01]: Cool, gehe mich bitte, wenn ich der Fall schliege, aber fast jede Standardrelationalen Datenbank ist es jetzt kompatibel, wenn du so möchtest. [SPEAKER_01]: Also ich rede von Oracle, von der MSS-Gürl, von normalisikul und zu weiter und zu fort. [SPEAKER_01]: Aber NoSQL als der Heip damals hoch kam, hat sich dadurch gefeiert.

[SPEAKER_01]: Okay, wir sind jetzt nochmal groß skalierbar und deswegen [SPEAKER_01]: sind wir in vielen Bereichen nicht asset-compatibel, sondern da kam dann etwas anderes zu vorstellen und das wird mehr oder weniger base genannt, ist das richtig, also base gliewelle will, ich weiß, dass das Efe, wenn schon Konsisten sich steht oder zwischen irgendwas mit steht, also

[SPEAKER_00]: Genau, kann man sich auch näher anhanden in unserer Episode 22, wo wir über dieses A-Sit-Base und so weiter sprechen. [SPEAKER_00]: Er wird auch kurz sich wieder mal gelesen, dass der Eric Brue der diesen Begriff erfunden hat, eigentlich auch sagt, dass es eigentlich so ein bisschen... Also nicht so schlecht definiert, zweitens hat einfach gut geklungen, war wollte halt... [SPEAKER_00]: Es sieht machen mit, was heißt es jeder auf deutsch eigentlich?

[SPEAKER_00]: Säure, genau, also sauer und Basis halt Basis und irgendwie hat man dann was suchen müssen für diesen Begriff und darum heißt es Basically Eurälebel, Soft State, Eventual consistent, aber eigentlich ist es nicht zu richtig definiert und im Prinzip beschreibt es einfach so diese Welt, die so mit der NoSQL Bewegung gegeben hat. [SPEAKER_00]: Dass man eben nicht mehr 100% Kontistent ist, sondern eventuell Konsisten sie hat.

[SPEAKER_00]: Und das, um bei Abschwächungen in dem ACT hat, weil wenn du wirklich ACT in dem Verteiltensystem hättest, dann bist du wahrscheinlich sehr, sehr langsam und hast ziemlich Probleme. [SPEAKER_00]: Da gibt es dann auch noch dieses Kapdäurem. [SPEAKER_00]: Da will jetzt gar nicht so in den Teil gehen, haben wir in Episode 91 besprochen. [SPEAKER_00]: Da gehen wir wirklich die, finde es Kapdäurem von Verteiltensystemen.

[SPEAKER_00]: Da geht's im Prinzip darum, dass man nicht alle drei Dinge, also des C, des R-D-SP, Konsistenz, Evelability oder Partition-Dollar-Ranz gleichzeitig haben kann. [SPEAKER_00]: Also man muss immer eine Seite leicht aufweichen, damit man einen Verteiltensystem sinnvoll arbeiten kann.

[SPEAKER_00]: Das heißt, [SPEAKER_00]: Man kann nicht konsistenz garantieren, wenn man gleichzeitig erlaubt, dass der Klasse die verschiedenen Knoten auch mal keine Verbindung mehr miteinander haben können. [SPEAKER_00]: Das ist zum Beispiel zwei Deile in dem Klasse gibt.

[SPEAKER_00]: Weil kann man sich ja vorstellen, wenn man so eine Split Brain Situation hat, das heißt, man hat zwei Klasse Deile, die beide noch funktionieren, aber die können nicht mehr miteinander sprechen, die zwei Deile, dann kann man natürlich auch keine konsistenz garantieren. [SPEAKER_00]: Weil der eine Seite vom Gehirn, vom Split Brain hat plötzlich einen anderen Städt als [SPEAKER_00]: Man kann nicht immer alles garantieren und es ist eigentlich dieses Kapdäurem.

[SPEAKER_00]: Das heißt, es ist der ganze Bereich von verteiltenssystemen weniger paralleles Systeme. [SPEAKER_00]: Es ist wirklich, wenn man über Netzwerk mehr Rechnoten hat und die miteinander verbindet. [SPEAKER_01]: Wer sich ein bisschen mehr mit dem Cap-T-O-RiM aus Nondos jetzt möchte, kann sich auch mal die Folge 90 von Medgenie und Kirs kann.

[SPEAKER_01]: Ich glaube, da haben wir eine ganze Stunde darüber gesprochen, mit deutlich mehr bei Spielen und auch wie zum Beispiel die ganze Tematik in Kavgau und Cassandra geliebt wird also in realen System.

[SPEAKER_01]: Bei dem Base-TO-REM fährt ich immer so den Leitsatz ganz interessant so merke ich mir das oft lieber irgendwann richtig als jetzt gar nicht mehr verfügbar und das ist halt genau dann das Ungekehrte von einem Esset so noch den Motto wie sind immer konsistent und bla bla bla bla es ist sofort richtig

[SPEAKER_00]: Gerade wenn man in dem Bereich von Verteiltensystemen weltweit Verteiltensystemen spricht, also was man halt fast immer hat, wenn man weltweit operiert, dann haben wir halt einfach einen klasse Not in Amerika stehen und einen in Deutschland z.B.

[SPEAKER_00]: und der habe das automatisch dieses Problem und muss mir irgendwas überlegen, was ist, wenn die Glaswasserleitung über den Oziern einfach mal gekabt wird oder nicht mehr funktioniert, was sie machen kann, ich kann sagen, Amerika arbeitet nicht mehr Deutschland, aber nicht mehr, und ich warte bis [SPEAKER_00]: Oder ist er kalt die Arbeiten beide noch parallel weiter, wie er dann vielleicht in Konsistenzen in meinem System und muss dann in irgendeiner Form später aufkommen?

[SPEAKER_01]: Wenn die Glasfaserleitung nach Amerika geklappt wurde und du hast keine Verbindung, würde ich an deiner Stelle nicht über Base oder Kaptierie oder so nachdenken, sondern eher über dein Infrastruktur-Provider,

[SPEAKER_01]: weil in der Regel liegen der zweifach bis dreifache Redundanzen und wenn ein Infrastruktur bei weider nicht die Leitungsbetreiber bezahlt damit in dieser Redundanzen nutzen darf, dann würde ich sagen, brauchst du über all das gar nicht nachdenken, wächstel erst mal den Proveider. [SPEAKER_01]: Weil das jetzt die Sales pitch von deinem Arbeit gibt, oder? [SPEAKER_01]: meines ist es nach haben wir keine eigenen Untersee-Kabel von daher pitt sich da gar nichts.

[SPEAKER_01]: Da musste ich da an die großen halberes Gehler, obwohl ich glaube, es gibt gar nicht so viele Firmen, die wirklich die Untersee-Kabel betreiben. [SPEAKER_01]: Es gibt zumindest so viele weiß nur zwei Schiffe oder drei Schiffe oder oder die Untersee-Kabel legen können. [SPEAKER_01]: Gugel und Facebook haben auf jeden Fall sehr viele Untersee-Kabel, mein ist bis jetzt. [SPEAKER_01]: Naja, die fangen jetzt an.

[SPEAKER_01]: Ich glaube, Meta fangt es an neue Zulegen oder so was, der Rest ist ziemlich gemietet. [SPEAKER_01]: Aber da müssen wir auch meine Episode, wo man machen, wie die Kabel eigentlich verteilt sind oder eine Ordnung. [SPEAKER_01]: Also, wer jemanden kennt aus dem Untersee-Cabel Business, gerne an unswenden. [SPEAKER_01]: Meine Frage ist eigentlich, warum entzählst du mir das eigentlich ja alles?

[SPEAKER_01]: Warum muss ich als Entwickler eigentlich so tief gehen und die Details von Konsistenz oder [SPEAKER_01]: Macht das nicht so wie so die Datenbank, also ich meine, da macht sich so viel Klogekörper für Gedanken. [SPEAKER_01]: Warum muss ich das jetzt alles wissen? [SPEAKER_00]: Das Problem ist, dass die Datenbank sich natürlich nur bis zu einem gewissen Krat den Kopf zu bricht über deine Probleme.

[SPEAKER_00]: Gerade wenn die die jetzt z.B. [SPEAKER_00]: frag, wenn du sagst du, du verwendest ja Postgres und Maestro L. Weißt du, was für Isolationslevels, die es dann noch ein bisschen eingeschalten haben? [SPEAKER_00]: Was du, ob du da jetzt ein Bankkonto-System drauf programmieren könntest? [SPEAKER_00]: Oder wenn du eine Transaktion startest, ob dir da eine andere Transaktion in deine Transaktion was reinschreiben kann oder ob das wirklich sauber isoliert ist?

[SPEAKER_01]: Also ob ich darauf, als man Bankkonto-System programmieren kann, ist die Antwort ja kann nicht, ob du das dann als Kunde nutzen soll, das ist eine andere T-Made. [SPEAKER_00]: Also, das macht vorne weg. [SPEAKER_00]: Aber was musst du machen damit du in Bankkonto-System oder ein Banksystem entwickeln kannst?

[SPEAKER_00]: Oder ist ja egal, und ein anderes System, wo die Daten wichtig sind, einfach, wo du nicht zu sagen kannst, wenn der Stadt fünf acht steht, ja, so schlimm ist es nicht, ist es nur ein Login-System oder so?

[SPEAKER_01]: Ja, mit mir hoher Wahrscheinlichkeit, mit diesem Konsistenz und die Situationen, in der willen wir außen anders setzen, aber ich kann jetzt auch nicht sagen, wenn ich jetzt so eine Standard-Distri-Rundhalade oder etwas von einem Heipass-Gäler meiner Wahl nutze oder eine Männestadenbank, was da jetzt im Detail eingestellt ist, nee, das kann ich hier nicht sagen. [SPEAKER_00]: Und genau, das ist eigentlich das Problem.

[SPEAKER_00]: Das heißt, man muss ja nicht im Detail verstehen, wie die Datenbank des Schlussendlich macht. [SPEAKER_00]: Aber man muss verstehen, was gibt es für Isolationslevels? [SPEAKER_00]: Was ist in der Datenbank aktiviert? [SPEAKER_00]: Welches Isolationslevel? [SPEAKER_00]: Was heißt es für mich als Programmieren? [SPEAKER_00]: Was muss ich bei mir machen? [SPEAKER_00]: Was über dem Detailbank?

[SPEAKER_00]: Und gerade, wenn man daran denkt, an Steve Backing, war findet jetzt irgendein Back, findet raus, irgendwo stimmt in der Datenbank, was nicht. [SPEAKER_00]: Dann zurückverfolgen, warum passiert das, wie wird da reingeschrieben? [SPEAKER_00]: Im Nachhinein ist das ganz schwierig voll, wenn es darum geht, paralleles Systeme zu handhaben. [SPEAKER_00]: Das heißt, 1000 User schreiben gleichzeitig auf die Datenbank, und dann hast du irgendwo falsche Daten.

[SPEAKER_00]: Und da musst du rausfinden, warum ist es passiert. [SPEAKER_00]: Und jedes Mal, wenn du ein Test machst,

[SPEAKER_00]: Stimmen die Daten, weil du natürlich selten 1.000 User simulierst, sondern immer nur dich selber auf deiner Defmaschine einmal probierst, da was zu schreiben und da ist es dann schon wichtig zu verstehen, was gibt es für Isolationslevels in welchem Isolationslevel aber die Datenbank und hat es irgendwelche Auswirkungen auf meine Transaktionen oder Kanda überhaupt so eine Nebenläufekeit, so eine Race-Kondition überhaupt entstehen.

[SPEAKER_00]: Und wer das kennt, auch jetzt aus einem klassischen Programmier umfällt, eine Race-Kondition ist super schwer zu debacken. [SPEAKER_00]: Leider. [SPEAKER_00]: Und da hilft ihr dann natürlich jede Information, die du über das System über das Verhalten des Systems weißt im Vorhinnern.

[SPEAKER_01]: Aber wenn ich da jetzt so eine Datenbank habe und wie das Schema ordentlich ausdenke und bei dem Schema alles ordentlich mit Primary Keys und Foreign Keys und Foreign Key in Constrains ordentlich Sätze. [SPEAKER_01]: Und natürlich mit ganz klassischen Transaktionen arbeiten. [SPEAKER_01]: Hab ich dann nicht zwei doppelte Netze, hab ich dann nicht auf der einen Seite Transaktionen, weil alle Stabilzimmer bei einer Transaktion sind ja konsistent.

[SPEAKER_01]: Und zwei, mich auch vor nennt man, dass Daten unintigereität geschützt. [SPEAKER_01]: Also, dass ich zum Beispiel nur eine Rechnung anlegen kann, wenn ich einen User angelegt habe. [SPEAKER_01]: Und so weiter.

[SPEAKER_01]: Also wenn diese Vorrünke Einschränkungen ordentlich gesetzt werden, dann... [SPEAKER_01]: bekomme ich doch eigentlich ein Fehler von der Datenmarkt zurück, äh, geht nicht und dann mache ich ein Rogue in einer Transaktion und dann steht das wieder in der Ögnum-Lock und dann geht wieder irgendein Entwicklerlos und Fixersprobe.

[SPEAKER_00]: Die Foreign Keys, die waren natürlich eingehalten, üblicherweise und da merkst du das auch nicht so richtig schwierig wird, einfach sobald du dann Änderungen durchfirst. [SPEAKER_00]: Das heißt, sobald du werte in der Datenbank anders und nicht nur du, sondern du aus dem User gleichzeitig.

[SPEAKER_00]: Das ist eigentlich so die Spirigkeit, da kommen dann die Feinheiten zu tragen, wenn du jetzt [SPEAKER_00]: Prüfe, ob für eine Rechnung auch eine User verhanden ist, so was wird natürlich immer gecheckt und das bekommst du auch gemeldet und es funktioniert.

[SPEAKER_00]: Wenn es jetzt aber darum geht, verschiedene User verschiedene Transaktionen in greifen auf dieselben Daten zu zählen, da 1 drauf, 1 runter, überweißen Geld irgendwie von Konto A nach B oder Kaufen was ein und du hast ein Lagerstand, der da hört wird und reduziert wird, dann kommt es schon in den Bereich, der recht schwierig ist, dass man da alles isoliert.

[SPEAKER_00]: Also wir waren ja schon [SPEAKER_00]: bei der Isolation von Aset und darum geht es natürlich auch bei den Isolationsmodellen, wie sehr sind deine User von anderen isoliert. [SPEAKER_00]: Also wie will sehen die von einander? [SPEAKER_00]: Und wenn da jetzt irgendwo nins Nika kauft und das Nika kauft in deinem Webshop um eins reduziert wird und das sind jetzt nur mehr eins Nika bar vorhanden oder null vielleicht sogar.

[SPEAKER_00]: Sieht es eine andere Tragen-Zektion, sieht es eine andere Transaktion nicht, da kommen dann so Feinheiten in Spiel und wenn es jetzt eben nicht muss nie kasseln, sondern Geld womöglich, dann ist es mit der ich schon relevanter tun konnte stand, siehst der gerade falsches, auf dem du dann Rechnungen anstest, du schaust mal nach wie hoch ist der konnte stand vom Andy? [SPEAKER_00]: Nimmst diesen Wert, zählst dann 300 Euro dazu oder ziehst was ab, dann muss der Wert natürlich stimmen.

[SPEAKER_00]: Dann kann es nicht irgendwo einen Zwischenwert sein, der gerade von einer anderen Transaktion geschrieben wird und am Ende kommt irgendwie ein falscher Kommtbestand raus. [SPEAKER_00]: Und genau da machen die Datenbanken dann schon Unterschied und garantieren die nicht automatisch alles und deshalb großes Problem, weil das dann abmäßig natürlich nicht aktiviert ist. [SPEAKER_00]: Okay, verstanden.

[SPEAKER_01]: Das gesagt aber auch, dass ordentlich vorm Key Constraint und so weiter und so fort, mich bei Deliz und bei Inzürz schon mal schützen, also das Sicherheitsnetz ist auf jeden Fall da, dann auch im Kontext von Parallelen Operationenrecht richtig verstanden habe. [SPEAKER_00]: Genau, und Klassiker zum Beispiel, du hast es dein Schubsystem mit den Sneakern und du machst eine Selektanfrage, wie viel Sneak hast du dann noch zur Verfügung, muss ich nachbestellen oder nicht.

[SPEAKER_00]: Jetzt kannst du Triggers plötzlich nachbestellen, weil du glaubst die Sneak [SPEAKER_00]: Aber in der Zwischenzeit wurden da vielleicht irgendwelche Transaktionen wieder abgebrochen. [SPEAKER_00]: Es wurde was nicht bestellt und die Chaos gehen wieder nach oben. [SPEAKER_00]: Das wisst du natürlich nicht haben. [SPEAKER_00]: Du wirst dann ein Konsistenten zustandt, weil das Volk Deuer ist, wenn du jetzt 1000 Neues nie krass bestellt, wieder in der Arke.

[SPEAKER_01]: Aber du sauchst ja gerade die Datenwag hat diese Funktion. [SPEAKER_01]: Diese Art von ich isoliere einfach alles von an anderem. [SPEAKER_01]: Warum ist das nicht der Standardwert? [SPEAKER_01]: Warum ist das nicht die void an? [SPEAKER_00]: Ja, du springst ja schon in die Isolationslevels rein und wenn man dadurch strengste Isolationslevel nimmt, das ist serializable, also sehr realisiertbarkeit und dieses Isolationslevel würde die eigentlich die Garantie geben.

[SPEAKER_00]: Das heißt, da hast du keine Probleme und das Problem, was du damit aber dann hast, ist, dass du nicht verdammt langsame Datenbank hast. [SPEAKER_00]: Das heißt, dann kannst du es fast schon sehr reale ausführen, deine User. [SPEAKER_00]: Das heißt, wenn da irgendwann Geld überweist, dann blockst du die gesamte Datenbank und dann kommt der zweite User dran, wenn da was überweist oder dem Webshop kauft.

[SPEAKER_00]: Das wäre natürlich nicht ideal, klar Banken oder sowas operieren hoffentlich in diesem Zustand und er ist schon ein bisschen schneller, also Datenbank bemüht sich da schon. [SPEAKER_00]: Aber man hat da schon einschnitten, über die Mal sagen, von 50 Prozent ungefähr. [SPEAKER_00]: Also, wenn du da wirklich auf den härtesten Isolationsmoderschaltest bekommst du 50% weniger durchsatz in deine Datenbank und das kann natürlich dann schon Probleme geben.

[SPEAKER_00]: Lesend ist ein bisschen weniger als Problem, aber gerade ist schreibend, ist es ein riesen Problem und da wird die Datenbank dann super langsam. [SPEAKER_01]: Also das bedeutet, wenn ich jetzt den Snekerkaufe und du möcht den Sneker auch kaufen musst du warten bis ich komplett den Sneker gekauft habe und bezahlt habe und dann kannst du erst losgen und dieser Sneker verkauft es richtig.

[SPEAKER_00]: Also das, was du jetzt beschreibst, ist ja die dumme Welt ist kein parallelles System, sondern ist ein System, wo jeder User jede Transaktion nachher an der abgearbeitet wird. [SPEAKER_00]: Was die Datenbank macht, die macht es schon Schlauer, die macht schon Parallelle aber weitung, die garantiert, die aber eine Serialisierbarkeit und die Serialisierbarkeit bedeutet genau das, die garantiert dir, dass du den selben Zustand danach hast, dass selbe Resultat wie.

[SPEAKER_00]: Also wenn du das hintereinander ausgeführt hast. [SPEAKER_00]: Darum sehr realisierbarkeit, also renimmst diese ganzen 5.000 User, die da alle irgendwie Geld überweißen Sachen kaufen und die Platenbank garantiert hier. [SPEAKER_00]: Da zustandt ist am Ende genau der, als wie wenn du die 5.000 User hintereinander ausgeführt hätte. [SPEAKER_00]: Es sind jedes Mal alles geblockt hätte es nur für einen einzigen User.

[SPEAKER_00]: Also, dass du das in einem Barreland System dummesystem hast, das wirklich nur hintereinander alles abarbeitet. [SPEAKER_00]: Und das ist diese Redisierbarkeit, das härteste und dann gibt es im Prinzip, es gibt eine ganz viele Isolationsmodelle, aber die üblichsten sind eigentlich drei andere, das ist Read Uncommitet, Read Committed,

[SPEAKER_00]: Und RepiTiBeriet, das sind so die Klassiker, die jetzt so meist koel einen Oracle, ein Postgres, eigentlich unterstützt und die vier Modelle gibt's mit kleinen Adoptionen und jeder sieht es ein bisschen anders, aber so im Groben und ganzen sind es so die vier Isolationslevers, die dann auch bedeuten, wie hoch. [SPEAKER_00]: Ist die Sicherheit und wie viel Oberhatt hat die Datenbank? [SPEAKER_00]: Also wie viel verlierst du dann vom Speed von der Datenbank?

[SPEAKER_00]: Und wenn du einen ganz normal dumme System hast, wo dir alle egal ist, dann kannst du dir sagen, ich will so eine grobe Sicherheit, meine Foreign Key sollen funktionieren, aber alles andere ist mir eigentlich egal, die will eine schnelle Datenbank haben. [SPEAKER_00]: Es geht sogar so weit damals die Myisem Storage Engine von MySQL die Kante gar keine Transaktionen. [SPEAKER_00]: Und die war trotzdem sehr beliebt, weise eben super schnell war.

[SPEAKER_00]: Und ganz oft in vielen US-Cases einfach die wesentlich schnellere Variante war und drum von Leuten durchaus verwendet wurde, wo es schon in der Db-Darmel-Skab mit Transaktionen und es jetzt kompetibilität. [SPEAKER_01]: Und wenn du jetzt sagst, ich will die schnellste Datenbank haben, trotzdem die Situationslöbe. [SPEAKER_01]: Dann sagst du, okay, es ist hier realizable, das schlechteste, was du machen kannst. [SPEAKER_00]: Welches ist denn das andere extrem?

[SPEAKER_00]: Das unterstell ist normalerweise read and committed. [SPEAKER_00]: Das heißt, jeder sieht eigentlich auch schon Informationen, die noch gar nicht zu fix geschrieben sind. [SPEAKER_00]: Also da kam mir durchaus so einiges reintpuschen von der Seite.

[SPEAKER_00]: Aber gewisse Grundlegenden, eben Transaktionen und so weiter werden wir auf jeden Fall noch garantiert und das klassische Problem, was man da hat, kennt man vielleicht auch so oder hat man schon mal gehört, ist eigentlich, dass man da die Reads hat. [SPEAKER_00]: Das heißt, man ließ Dinge, die eigentlich noch nicht. [SPEAKER_00]: fix geschrieben sind.

[SPEAKER_00]: Das heißt, wenn du uns nie kakaust, steht in der Datenbank vielleicht schon, dass du jetzt einen Snicker weniger im Lagerstand hast, obwohl diese Transaktion noch gar nicht abgeschlossen ist, obwohl der noch gar nicht durch die Kreditkarten, Prozesse durch ist und den Kauf wirklich abgeschlossen hat, sehen andere schon Snicker wurde um ein reduziert.

[SPEAKER_01]: Und wenn ich dann den Kauf abbreche, dann ist der Sneaker ja wieder im Lager, du denkst aber das Sneaker ist ausverkauf und hast du mit eigentlich ja ein Dirty Read also dann einen unwahren Lesevorgang gemacht richtig.

[SPEAKER_00]: Genau, Dirty Read ist überhaupt so eine überklasse, also das ist so das größte Problem, eigentlich oder wo sich die Isolationsleverstern unterscheiden, aber Dirty Read hast einfach ich leese was, was eigentlich nicht konsistent ist. [SPEAKER_00]: Also ich bin in einem quasi inkonsistenten Zustand zwischen drin. [SPEAKER_00]: Und lasse Daten, die unkältig sind, weil eben der User dann vielleicht abricht, den Kauf oder vielleicht irgendwo ein Datlock entsteht.

[SPEAKER_00]: Zum Beispiel kann ja auch automatisch sein irgendwo entsteht ein Datlock. [SPEAKER_00]: Jetzt werden Transaktionen wieder zurückgerollt. [SPEAKER_00]: Das heißt, rückgängig gemacht. [SPEAKER_00]: Und ich habe aber gerade ein Selectstatement gemacht, lasse Daten, die dann in der Zukunft nicht mehr geltig sind. [SPEAKER_00]: Oder in dem Moment vielleicht gar nicht geltig waren, weil eben die Transaktionen noch nicht abgeschlossen haben.

[SPEAKER_01]: Ich habe gerade mal ChatGP dir gefragt, ob die mir irgendwie so ein kleinen Merk-Satz geben kann. [SPEAKER_01]: Jetzt bin ich gespannt. [SPEAKER_01]: Ja, ich muss mir immer solche Sars merken mit Dätzen. [SPEAKER_01]: Dirty Read ist wie ein Gerücht du hörst, es bevor es stimmt und am Ende war es doch falsch. [SPEAKER_01]: Kommt euch hin oder? [SPEAKER_00]: Ja, ja, kommt doch aushin.

[SPEAKER_00]: Problem ist, vor allem, wenn ich halt eben auf den Gerüchten, die da herre, in der andere Reaktion setzen. [SPEAKER_00]: Wenn es jetzt nur die Gerüchte sind, die dann vielleicht nicht hundertprozentig stimmen oder so, ist ja okay, aber das Problem ist, wenn ich dann Entscheidungen dreifel, basierend auf den Gerüchten und das Gerücht ist nicht wahr, dann haben wir noch durch einen Problem und wenn ich ihn erherr.

[SPEAKER_00]: Nach Bestellung auslöße von 10.000 Nika, so ein neuen Lkw voll das Nika ist, obwohl vielleicht noch genügend Nika sie in meinem Lager werden, dann habe ich natürlich ein Problem. [SPEAKER_01]: So, und daher studiert habe und du sagst, dass Ding heißt Read-Ancommitet, die stark davon aus, es gibt ein Isolationslevel namens Read-Commitet. [SPEAKER_00]: Also, das ist eigentlich so das Standard, den die meisten Datenbanken als die voll eingestellt haben.

[SPEAKER_00]: Buskress hat das meist kuelles ein bisschen strenger, wobei die haben dann eine andere Definition von Insolationslevel, also vielleicht ist das E-Ungefähr selbe. [SPEAKER_00]: Aber Read committed, sagt eigentlich genau das, was halt dann auch mehr auch aus sagt. [SPEAKER_00]: Das heißt, man kann Werte lesen, die schon committed wurden. [SPEAKER_00]: Das heißt, alle Transaktionen, die abgeschlossen wurden, von denen kann man die Werte lesen, wenn man abfragen macht.

[SPEAKER_00]: Gib immer dein Sneaker bei Schwöde wieder, was heißt das? [SPEAKER_00]: Ich kaufe den Sneaker, ich bin im Warenkorb. [SPEAKER_00]: Genau, du hast den Warenkorb ab, machst die Bestellung. [SPEAKER_00]: Während du die Bestellung machst, sieht noch niemand, dass du den Sneaker gekauft hast, wenn du den Beibarten am Schluss gedrückt hast, dedicaten Daten eingegeben hast, alles durchgelaufen ist, dann wird es besistiert, dann sehen alle, dass du den Sneaker gekauft hast.

[SPEAKER_01]: Das bedeutet aber auch, ich leg mir den in den Warenkorb, ich gehe in den Checkout. [SPEAKER_01]: Du siehst, der Sneaker ist noch verfügbar und kannst auch in den Checkout gehen. [SPEAKER_01]: Und Chris erst später an den Fehler, wenn ich meine Traaktion abgeschlossen habe, ist das geregt. [SPEAKER_00]: Ja, das ist ja ein bisschen das Problem.

[SPEAKER_00]: Und das ist genau, was Redcommitted eben nicht verhindert, weil bei Redcommitted werden sogenannte Non-Repeatable oder Phantom Reads erlaubt, bzw. [SPEAKER_00]: sind noch immer möglich. [SPEAKER_00]: Das heißt, ich bekomme keine Fehlermeldung. [SPEAKER_00]: Wasser, was Problem ist, bzw. [SPEAKER_00]: was bei steigeren Isolationsmodels zerwolder Fall ist, ist, dass wenn ich einen Wert leese, das ist dieses non-rebyte Brüm, ich leese jetzt, wie viel Sneaker sind vorhanden.

[SPEAKER_00]: Ein Sneaker. [SPEAKER_00]: Jetzt arbeite ich mit dem Wert ein Sneaker weiter in meiner Transaktion, mache irgendwas damit. [SPEAKER_00]: Jetzt kommst du und kaufst den Sneaker. [SPEAKER_00]: Erzeugt es, du eigentlich gar nicht mehr in der Lage sein, diesen Wert zu ändern. [SPEAKER_00]: von Sneaker 1, Lagerstand 1, auf Lagerstand 0, warum, weil ich den Jahr gelesen habe.

[SPEAKER_00]: Und dieses Gerücht, der z.B. [SPEAKER_00]: ist kein Gerücht, das ist der richtige Wert, Sneaker Lagerstand 1, ich gehe davon aus, der stimmt jetzt und arbeite damit weiter. [SPEAKER_00]: Jetzt endest du den Lagerstand auf Null, Kaufstens Nika, damit wird diese Informationen plötzlich ein Gerücht bzw. [SPEAKER_00]: Falscherwert für mich, weil der in der Zwischenzeit sich der geändert hat.

[SPEAKER_00]: Das heißt, bei einem strengeren Isolationslevel, der kein non-rebeatable read erlaubt. [SPEAKER_00]: Darf es eigentlich nicht der Fall sein, dass wenn ich eine Informationen gelesen habe und ich noch immer sage, ich arbeite mit der Informationen, das heißt, meine Transaktion ist noch nicht abgeschlossen, darf niemand anderer den Wert ändern. [SPEAKER_00]: Weil ich ja die, sonst eine Information habt, die unkultig wird, automatisch.

[SPEAKER_00]: Und das wird bei Read Committed nicht verhindert, sondern ist immer noch ein Problem. [SPEAKER_00]: Und das nennt sich non-Rebyte beriet, das heißt, wenn ich jetzt ein Welt neu lesen würde, nachdem du den Sneaker gekauft hast, bekommen einen anderen Welt, als wie vor 30 Sekunden, wo ich den Welt auch gelesen habe. [SPEAKER_00]: Und eigentlich ist es unkältig, weil in einer Transaktion volle Isolation muss ich immer den gleichen Wissen stand haben.

[SPEAKER_00]: Es kann nicht sein, dass sie wenn ihr ihn zerleckt, nochmal ausführeret, dass ihn anderen Welt bekommen. [SPEAKER_00]: ZweiSeleckt sind einer Transaktion müssen immer des selben Wertrück gehen. [SPEAKER_00]: Wenn ich sehr redisierbar bin. [SPEAKER_00]: Nein, man lasst dann Repetivaryt. [SPEAKER_00]: Was genau? [SPEAKER_00]: Also wenn es funktioniert. [SPEAKER_00]: Ja. [SPEAKER_00]: Also wenn du zwei Selekt in einer Transaktion zahlst.

[SPEAKER_00]: Und kann man vielleicht so nennen, wenn du willst, aber am Moment auf jeden Fall die nächste Isolationsstufe Repi-Depariet wo das eben genau nicht erlaubt wird, dass du bei zwei Selektanfragen unterschiedliche Werte zurückbekommst in der selben Transaktion. [SPEAKER_00]: Also das ist genau die nächste strengere Variante und die nennt sich Repi-Depariet. [SPEAKER_00]: Was aber bei dem, isolationsmodell, sehr wohl noch ein Problem ist, sind Phantom Reads.

[SPEAKER_00]: Also, ihr will schon zuerst erwähnt, bei Red-Competit ist das Problem, dass non-Repeatible Reads erlaubt sind und Phantom Reads, oder erlaubt möglich sind, grundsätzlich, bei Red-Berät, natürlich keine non-Repeatible Reads mehr, aber Phantom Reads können noch auftreten, wobei es kommt, auch ein bisschen darauf an, wie das Implementiert ist, da unterscheiden sich die Datenbanken leicht.

[SPEAKER_00]: Meist Kuell ist das so ein Klassiker, da chapsen, [SPEAKER_00]: Transaktionsisolationsgueruh, würde ich mal nennen, der auch sehr verdästet in den Bereich und wirklich die Datenbanken probiert zu überprüfen, ob die wirklich sauber auch arbeiten. [SPEAKER_00]: Der macht sich da immer auch lustig, weil meist Kuell, da immer so ein bisschen herum diskutiert, ob sie jetzt forbidden oder nicht sind.

[SPEAKER_00]: Weil du schon ein Problem hast, dass sich da Datensetze durchassändern können, obwohl du sie gelesen hast.

[SPEAKER_00]: wirklich eine höheres Isolationslevel machen oder MariaDB hat dann fix für diesen Back neue things auf im neuesten Investition ist es glaube die fortmäßig aktiviert, dass das wirklich ein sauberes Repi-Tippe-Reed Isolationslevel ist und wirklich keine non-Repi-Tippe-Reeds basieren aber wie gesagt Phantom-Reeds können noch basieren Phantom-Reeds, Phantoms, Daten sozusagen sind Daten, die eigentlich noch gar nicht da sein sollten.

[SPEAKER_00]: als sie geinsertet wurden, zum Beispiel in der Zwischenzeit, also ich leese plötzlich irgendwelche Daten, die erst in der Zukunft eigentlich gültig sein sollten. [SPEAKER_00]: Das heißt, ich leese zum Beispiel irgendwelche die Anzahl der User bekommen da 300 zurück, dann leese ich noch mal, bekommt plötzlich 300 zwei zurück, weil in der Zwischenzeit zwei User eingefügt wurden sind.

[SPEAKER_00]: Also das sind so Phantom Reads, die eigentlich nicht passieren dürften, [SPEAKER_00]: weil die eben in der sauberen Isolation des gar nicht zehn dürfte, aber da weicht man dessen noch ein bisschen auf. [SPEAKER_00]: Also es ist eine Untergruppe von Non-Rebete-Berwitz. [SPEAKER_01]: Wurru-Grad-Jepsen erwähnt hast, ich lees dem seine Blockpost recht häufig.

[SPEAKER_01]: Auch mal sehr lange um diese zu lesen, denn ich hab immer so ein Arthwörterbuch daneben, weil ich mal nachkuchen muss, was bedeutet.

[SPEAKER_01]: Also ein bisschen wie früher in der CT und die X. [SPEAKER_01]: Ich habe mir ganz oft die ZT gekauft und öfter mal die EX, die EX habe ich damals noch nicht ganz verstanden, weil er ganz wahnsinnig viele Fachbegriffe drin haben, habe ich immer für das Lesende EX deutlich länger gebraucht, dass für das Lesende ZT und so ähnlich geht es mir. [SPEAKER_01]: mit den Japsenblockartikel.

[SPEAKER_01]: Und immer wenn ich die Lese dann kommt auch öfter mal ein Begriff vor, den nennt sich Wright-Skyu. [SPEAKER_01]: Und da steht dann oft irgendwie so im Begriff auch, so mit Phantom Reads, Dirty Reads und so weiter. [SPEAKER_00]: Kannst du mir den kurz erklären? [SPEAKER_00]: Es gibt übrigens ganz viele solche Phänomene.

[SPEAKER_00]: Glaubst du 20 oder so immer im ASK-Standert, im ASK-Standert sei schon, im Anzies-Standert von SQL sind schon so Phänomenä erwähnt worden und dann gibt es natürlich später Babers, die das auch noch erwähnt haben und mittlerweile referenziert man diese ganzen Phänomenä, die es da gibt, also diese Probleme bei den

[SPEAKER_00]: Mit einem Buchstaben und Nazzal, also wer das mal sehen sollte, zum Beispiel Phantom Redis P3 und P3 kommt aus dem Anzies Standard damals aus dem Original Dokument, das sind die ganzen P-S, die durchnummeriert sind, dann später hat es vom Cup de Orem so was gegeben, das ist meistens mit G, da gibt es dann irgendwie G1A und so weiter.

[SPEAKER_00]: Und BrightCue ist zum Beispiel A5B, das war dann ein späteres Späpper, wo so ein kritisches Späpper zu isolationslaborist, dass das eben alles nicht so funktioniert, wie man früher angenehm hat und dass der Probleme gibt und da gibt es eben das BrightCue. [SPEAKER_00]: und das sagt eigentlich nichts anderes aus, dass zwei Transaktionen gültig sind, dass da alles passt. [SPEAKER_00]: Aber wenn man sie hinteran der Ausführt, dann gibt's ein inkonsistenten Zustand.

[SPEAKER_00]: Also, in sich sind sie alle logisch stimmen alle. [SPEAKER_00]: Aber wenn man sie dann komplett ausgeführt hat, gibt's im Nachhinein einen falschen Zustand. [SPEAKER_00]: Und das kann man natürlich nur, [SPEAKER_00]: Verhindern in dem wir das im Nachhinein immer auch prüft, gibt es irgendwie Probleme, wenn diese zwei Transaktionen parallel auftritt. [SPEAKER_01]: Jetzt noch mal für Dumme, denn wir nehmen Sonntagabend auf und das Wochenende mal wieder anstrengt.

[SPEAKER_01]: Also wenn es die Regel gibt, das immer ein Mitarbeiter im Lager sein muss. [SPEAKER_01]: Und aktuell jetzt gerade zwei Mitarbeiter im Lager sind und Mitarbeiter auf den Dienstplan guckt und sagt, ja, mit dabei ist ja da, deswegen gehe ich nach Hause und mit dabei dabei in einer anderen Transaktion auf die Dienstplan guckt und sagt, ja mit dabei da ist ja im Lager, deswegen gehe ich nach Hause, ist ja das Entrisal resultat, dass niemand mehr im Lager ist.

[SPEAKER_01]: Es ist richtig, weil das ein Rights View, weil die zwei Leute ja in zwei Transaktionen auf den Dienstplan guckt haben und dann angenommen haben, der andere bleibt im Lager und deswegen beide gehen. [SPEAKER_00]: Es ist immer ein bisschen schräg aus der Realität, solche Beispiele zu bringen, weil wenn man auf einen Tischplan schaut und so das sind halt keine klassischen Transaktionen, aber im Endeffekt hast du natürlich recht.

[SPEAKER_00]: Es geht darum, wenn es abhängigkeiten gibt, die aus dem Nachhinein klar werden. [SPEAKER_00]: Also, es sind auch so checkst zum Beispiel, wenn man eine gewisse maximal Anzahl erlaubt.

[SPEAKER_00]: Also, wenn du zum Beispiel ein Lebensmittelhandler nimmst und du hast dann im maximal Anzahl an [SPEAKER_00]: z.B. [SPEAKER_00]: dann hast du dann durch immer ein Check drin und wenn du in zwei verschiedenen Fenstern z.B. [SPEAKER_00]: irgendwie article hinzufügt, dann kannst du dich passieren, dass diese Gesamt Summe überschritten wird, obwohl bei dem einzelnen Check natürlich das immer geklappt hat.

[SPEAKER_00]: Also das sind so Sachen, die Summeter Checks eigentlich Meter Konsistenzen überprüfen, kannst du aber wenn du Repetibaritasst kannst du diese inkonsistenzen verhindern, bzw. [SPEAKER_00]: das Phänomen ist dann eigentlich nicht möglich. [SPEAKER_00]: wenn du niedriger die Isolationslevels eigentlich hast. [SPEAKER_00]: Weil da ja gecheckt wird, wenn du was gelesen hast, darf sich der Wert nicht mehr ändern.

[SPEAKER_00]: Und das ist eigentlich der große Unterschied wie gesagt, bei meinem Skuel ist es nicht so hart, da muss man teilweise zelleckt vor Update schreiben. [SPEAKER_00]: Das heißt, man muss meist kuell mit deinen Hey, dieses Selekt, ich lasse jetzt was, dass ich später irgendwie ändern kann und dann wird es wirklich gesperrt.

[SPEAKER_00]: Weil im Hintergrund geht es im Umsparen, was wird gesperrt und eigentlich, sobald ich was lasse, müsste ich das eigentlich sparen und drum ist, ist so super komplex. [SPEAKER_00]: Lesen irgendwas und die muss da plötzlich sparen im Hintergrund erstellen, gibt es da schon sparen 5.000 Leute, das jetzt gelesen. [SPEAKER_00]: Was ist denn das in Zukunft enda?

[SPEAKER_00]: Hat es gelesen, jemand in der aktiven Transaktion, als das wird schon super komplex und genau darum, ist eigentlich dieses Repetieber Read so komplex und wird standardmäßig, meistens nicht aktiviert. [SPEAKER_00]: Weiß ganz viel Overhead hat und dadurch die Performance reduziert. [SPEAKER_01]: Wie die Backtman oder testet man so was denn?

[SPEAKER_01]: Weil ich kann mir vorstellen, ohne eine komplett detailliertes Auditlock, welche Record-Bandivog schreiben wird, vielleicht so eventzursing. [SPEAKER_01]: Kann man so was ja kaum nachvollziehen. [SPEAKER_01]: Also wie testig ich sowas? [SPEAKER_00]: Im Prinzip passt es so ein Eventzursing, aber das ist eine Implementierung. [SPEAKER_00]: Sache kann man auch noch kurz darüber sprechen.

[SPEAKER_00]: Grundsätzlich, wie so was getestet wird, du kannst es natürlich nicht mit Junitests testen, weil die haben kein echtes Barallelles verhalten. [SPEAKER_00]: Also da kannst du ja schwer testen, vorher jetzt 1000 Barallelle User auf mein System ein, das machen Junitests einfach nicht.

[SPEAKER_00]: die für Dests, also Fassing, was wir schon in Episode 188 übrigens besprochen haben, bei der Meiner sich damit befassen will, also dass man randomisiert oder solide randomisiert oder randomisiert, aber mit einem gewissen Ziel ganz viele DEST-Daten-Sätze, DEST-Use, was es dann auch immer sind, ausführt und einfach mal schaut, gibt es irgendwo ein Problem, wenn ihr da einfach da uns in der Sachen drauffeuer, da findet man natürlich auch gewisse Dinge.

[SPEAKER_00]: Es gibt aber auch die deterministische Simulationen, also wo man sehr genau definiert, was passiert jetzt. [SPEAKER_00]: Und da ist Chapsen, den wir jetzt schon erwähnt haben, mit seiner Test sieht auch ganz vorne dabei. [SPEAKER_00]: Der simuliert dann wirklich mehrere Kleins, mehrere User und hat dann genauer abfolgen. [SPEAKER_00]: Da war sehr zufällig und natürlich die dann prüfen, ob eben zum Beispiel so ein Repetable Read.

[SPEAKER_00]: Phänomenen auftritt, das heißt, wenn man zwei Transaktionen hat, die unterschiedlich sich gegenseitig beeinflussen und schreiben, hat man dann vielleicht irgendwo ein Selechtsdästern beim zweiten Mal in falschen Weltrausbringt oder zu viele Zahl, zu wenige Zahlen. [SPEAKER_00]: Also, ob man da irgendwo Daten hat, die eben zu diesem Zeitpunkt eigentlich nicht da sein sollten.

[SPEAKER_00]: Und Chapsen hat dann eine riesen Bibliothek natürlich an Problemfällen schon drinnen und kann die dann prüfen und ausführen und so deste da auch die ganzen Datenbanken, [SPEAKER_00]: durch.

[SPEAKER_00]: Was der auch in seiner Destiny noch dazu hat, ist diese Fault-Injection, die man ja auch so ganz klassisch vom Chaos-Monkey-Kent, der dann irgendwie Netzwerk abschaltet, plötzlich oder Langzimmer macht, das kann schäpzen natürlich auch und macht-chäpzen auch, also massimuliert an das Sachen, wenn was ausfällt, wenn die Fassplatte ausfällt, wenn die Fassplatte zu langsum ist, wenn sich die Zeit plötzlich endet, vom Petripsystem, also hat es dann auch irgendwie einfluss oder wenn, bei einem

[SPEAKER_00]: Also man in checktet, man injeziert, damit man es damals auch deutsch sagen, damit man jetzt wieder beschwerden bekommen, mit zu vielen Anglizismen, man injeziert Fehler in das ganze System und schaut dann, wie verhält sich die Datenbank oder das Barrelaisystem und gibt es der Probleme. [SPEAKER_00]: Im Nachhinein muss man natürlich auch viel vereffizieren.

[SPEAKER_00]: Das heißt, man bekommt dann Resultate und wer effiziert dann durch, war das wirklich alles korrekt, dass man geht dann Schritt für Schritt die Transaktionen durch, wer effiziert ist im Endeffekt an das genauso. [SPEAKER_00]: Also, wenn man jede Transaktion hinter andere ausgeführt hätte, ist da immer alles valider. [SPEAKER_00]: in den Zwischenschritten und nur dann funktioniert es. [SPEAKER_00]: Und wenn man sich das ansieht und das ist wirklich erschreckend.

[SPEAKER_00]: Also, ihr empfehle jeden mal auf die Chapsen, website zu gehen, weil da alles öffentlich ist. [SPEAKER_00]: Der hat viele Tugs, der hat Protokolle, was er nicht alles gedeutet hat, in ihr verschiedensten Datenbanksystemen, Datenbankhersteller Zahlen, den mittlerweileen auch, dass er diese Dests durchführt, weil er eben so bekannt ist. [SPEAKER_00]: Und es ist erschreckend. [SPEAKER_00]: wie viel Probleme die Datenbanken haben.

[SPEAKER_00]: Also wo man so irgendwie denkt, die Datenbank ist ja sicher und die sie sind eine Datenbank dafür habe ich eine Datenbank und dann sieht man da Listen und Probleme, die nicht funktionieren und Fehlerhaftet Daten und so weiter. [SPEAKER_00]: Also es ist echt auf der einen Seite erscheckt, aber auch spannend, was man da alles rausfinden kann.

[SPEAKER_01]: Ich weiß gar nicht, ob das erschrecken sind, er kochen die Aufnümmet, was da und B zeigt es eigentlich das Problem, wie komplexes eigentlich ist, Daten parallel zu verarbeiten und irgendwie konsisten zu halten. [SPEAKER_01]: Also ich, wenn ich dir dazu höre mit Rights, Geon, Phantom, Read, dann hast du immer diese, diesen Trade-Off zwischen, mache ich jetzt alles serialisable, also eigentlich super langsam.

[SPEAKER_01]: Oder solge ich noch irgendwie dafür, dass ich ein schnelles Performance System habe. [SPEAKER_01]: Alles unter der Prämisse. [SPEAKER_01]: Ich habe Daten in die Integrität und Konsistenz am Ende. [SPEAKER_01]: Also, deswegen ich bin nicht überrascht, dass der Jobs in der Fehler findet. [SPEAKER_01]: Ich bin eher froh drum, dass jemand so hoch intellektuell fähig ist, Software zu schreiben und wirklich deterministische Situationen.

[SPEAKER_01]: auszuführen auf den Datenbank, um diese ganzen Sachen rauszuholen. [SPEAKER_00]: Und das Problem ist auch mit dieser Komplexität. [SPEAKER_00]: Auch wenn du jetzt deine Datbank auf serrealisierbar schaltest, weil du sagst, okay, ich will einfach ein sicheres System haben, da macht mir die Datenbank des schon automatisch.

[SPEAKER_00]: Das bedeutet aber auch, dass du zum Beispiel vielmehr rollbacks hast, am Ende des heißt, dass deine Transaktionen weil man draufkommt, irgendwo gibt's ein Problem. [SPEAKER_00]: Ihr habt dann Konflikt mit einer anderen Transaktion. [SPEAKER_00]: Dann wird mir die Transaktion wieder zurückgeräult. [SPEAKER_00]: Und Schätzungen gehen da ungefähr von 30 Prozent aus.

[SPEAKER_00]: Das heißt, ihr 30 Prozent mehr rollbackspletzlich, wenn ihr mit der Datenbank arbeite und das betrifft mich dann als Entwickler in natürlich. [SPEAKER_00]: Weil die Macht der Ögnetransaktion und dann wird die zurückgerollt. [SPEAKER_00]: Dann muss ich in meiner Applikationslogik mir überlegen, was mache ich denn, wenn jetzt eine Transaktion zurückgerollt wurde.

[SPEAKER_00]: Start die einfach noch mal in der Neue, was mache, wenn sich jetzt weiter geändert haben, der User hat vielleicht was anderes eingegeben oder auf einem anderen Stand operiert, [SPEAKER_00]: als den den Sie jetzt gibt, das heißt, die muss ich in der face irgendwas anzeigen, sagen, hey, sorry user, aber es hat sich was geändert, wo möglich ist, ist es aber nur eine banane, hat die schon was geklärt, banalität, aber damit muss man auch umgehen.

[SPEAKER_00]: Also es hilft auch gar nicht, das einfach zu sagen, okay, wir stellen das Isolations Level auf Serie Leisebel und dann ist alles gegessen, also auch das funktioniert nicht. [SPEAKER_01]: Jetzt möchte ich ja auch was lernen, auch für die zukünftige Entwicklung, das ich natürlich als so verentwickler selbst besser werde, denn was du mir jetzt mitgegeben hast, ist Kluxcheiser material.

[SPEAKER_01]: Schön beim Kaffeeshätt, mal eben, haben wir das einen Rideskyo drommen und dann direkt wieder weggehen. [SPEAKER_01]: Deswegen erklemmen wir, wie die ganze Sache unter der Hauptfunktion, wie machen die Datenmarken die ganze tematikdown? [SPEAKER_01]: Damit ich das vielleicht auch mal irgendwo ein Burgsichting so. [SPEAKER_00]: Also jetzt kommt eigentlich das Klugscheiße, wissen wir, weil das braucht man nicht mehr unbedingt wissen, wie die Datenbank das im Hintergrund macht.

[SPEAKER_00]: Aber mich interessiert so, was zumindest immer wie das funktioniert, ist eigentlich gar nicht so super schwer, wenn man sich das so konzeptionell durchüberlegt. [SPEAKER_00]: Also klassisch verwendet man mal die Version Konkarency Control, also MVCC, hat man vielleicht schon mal irgendwo gelesen. [SPEAKER_00]: Die ganzen klassischen Datenbackmeiß-Koll-Boss-Gressen zu weiter die funktionieren, alle mit dem MVCC. [SPEAKER_00]: Und eigentlich verfolgt es nur ein ganz einfaches System.

[SPEAKER_00]: Das heißt, jedes Mal, wenn ich etwas schreibe, hinzufügige Änderere, dann ändere ich nicht die eigentlichen Daten, sondern schreiben neuen Datensatz.

[SPEAKER_00]: Und der neue Datensatz wird einfach durchnummeriert, schreibe genau dazu, der gehört gerade aktuell zu dieser Transaktion, diese Transaktion läuft noch.

[SPEAKER_00]: Und jedes Mal, wenn ihr mit der Datenbank spreche und irgendeinen Selektzeit mit Abfrage muss sie mir überlegen, welche Transaktionen darf ich schon lesen, welche muss ich noch weglassen, muss ihr irgendwelche Update mit reinnehmen, lässt sich die Originaldaten, also einfach so eine historische Datenbank, eigentlich die mehrere Versionen haben kann. [SPEAKER_00]: Und das ist eigentlich alles. [SPEAKER_00]: Und so kann man die verschiedenen Transaktionen abbilden.

[SPEAKER_00]: Am Ende muss man natürlich irgendwann so ein Klin abmachen, welche Transaktionen wurden schon abgeschlossen, muss ihnen Wert überschreiben, den eigentlichen Wert. [SPEAKER_00]: Also da gibt es dann natürlich Prozesse, die relativ kompliziert sind, muss man sagen, aber die Grundidee, dass man einfach alles mit Zeitstempeln, mit Transaktionenstempeln verset und einfach nie, den Wert ändert, sondern immer nur was hinzufügt.

[SPEAKER_00]: ist eigentlich relativ easy und so kann man dann eigentlich relativ schnell so ein System bauen und dann die verschiedene Isolationslevels, denn die Isolationslevels sind dann natürlich unterschiedlich implementiert, weil man es dann darum geht, was wir sperren, setzliche Aufweche, daten setzen muss ich sperren, wo ich keine Rezmeer, wo ich keine Reizmeer und diesen ganzen Dinge, also das wird dann schon schnell komplex vor allem wenn in Richtung sehr realisierbar kaltgehend.

[SPEAKER_01]: Kann ich denn als Entwickler, der jetzt ganz doch auf das SQL-State-Menschreibt oder die Transaktion schreibt, dieses Isolationsmodell irgendwie anpassen, kann ich sagen, jetzt für diese Transaktion möchte ich dieses Isolationslevel oder vielleicht sogar für die Verbindung oder wird das irgendwie cluster global eingestellt oder Datemang global.

[SPEAKER_00]: Also grundsätzlich kann man das System weit natürlich einstellen und meine Meinung nach macht das wahrscheinlich auch Sinn eher System weit einzustellen, aber du kannst es auch je nach Datenpunkten natürlich feinkranulare Einstellen pro Connection zum Beispiel.

[SPEAKER_00]: Aber man muss natürlich auch dazu sagen, er ist dann natürlich auch schwierig, fallen wenn du mehrere User hast, andere User die vielleicht dann... [SPEAKER_00]: diese Kriterin nicht einstellen, die isolationslevels und so weiter. [SPEAKER_00]: Also ich würde schon eher auf Systemen level machen, wenn man natürlich jetzt nur ganz spezielle Bereiche hat, wo man das ganz strenge Modell sehr redisierbarkeit braucht.

[SPEAKER_00]: Dann kann man das natürlich auch jetzt für eine Queryfine Connection natürlich machen. [SPEAKER_00]: Und was natürlich da der Vorteil ist, dass ich jetzt als Programmierer das vielleicht auch machen kann, ohne dass ich den Datenbankatministerate dann frage, kannst du das System weit aktivieren.

[SPEAKER_00]: Aber da sollte man sowieso sprechen, weil, wie gesagt, das hat extreme Einfluss auf die Geschwindigkeit auf die Performance und dann sollte man vielleicht mit dem Datenbankatministerate doch sprechen, ob man das übermachen sollte oder nicht. [SPEAKER_00]: Da vielleicht die richtige Kommunikation wählen, aber grundsätzlich ist man da flexibel.

[SPEAKER_01]: Ich bin mir gar nicht sicher, ob man das dann wirklich machen sollte, die ganze Sache pro Transaktionen sogar einzustellen, weil du hast natürlich schon einen Hartenwild wuchs, ne? [SPEAKER_01]: Also, jetzt stell dir vor, du leust den Datenmarklast auf Isolationslevel 1, in der Transaktion schalltest du mal auf Isolationslevel 2 und so weiter, das später zu di bagen, das kriegt auch keiner mehr mit.

[SPEAKER_00]: in der realen Welt ist natürlich schon oft so, dass der Großteil deiner Daten wahrscheinlich egal ist, was du damit machst und dann hast du vielleicht zu einsweißachen, eben der Konto stand oder irgendwas, wo du dann vielleicht schon das Isolationslevel haben bist. [SPEAKER_00]: Also, wie kann man schon vorstellen, dass das in der Realität so gemacht wird, auch wenn man die Geschwindigkeit trotzdem hochhalten will.

[SPEAKER_00]: Aber wie gesagt, das kommt dann wirklich drauf an, wie für die Usommann hat und ich sehe auch [SPEAKER_00]: dass man da halt womöglich dann echt Probleme hat fallen, wenn man es dann irgendwo vergisst, dann machst du dann eine Transaktion vergisst, aber das ist die Solution-Slevel zu setzen und gehst aber davon aus, dass das ist die Solution-Slevel den höhere ist und dann, ja, spiel Spaß beim Dibacken.

[SPEAKER_01]: Wenn ich jetzt sage, das ist ein hartkomplexes Thema und vielleicht macht das, genau der Unterschied zu. [SPEAKER_01]: Ich bin Entwickler und arbeite mit einer Datenbank, oder ich bin Datenbank an den Strato- und Optimiere, wirklich Schema und Konsistenz, die Modelle und alle Drohne dran, oder? [SPEAKER_00]: Man muss natürlich sagen, dass die Datenbankatmen ist trittoren.

[SPEAKER_00]: Also ich will jetzt niemand auf die Fische treten, aber wahrscheinlich schon eher so ein Ausstärbender Job. [SPEAKER_00]: Teil sind, würde mal sagen, eine Position und das vielmehren Richtung die Weltupment geht. [SPEAKER_00]: Und die Leute, die ja selbst, die ihre Infrastruktur hochfahren. [SPEAKER_00]: Und da in der Cloud einfach eine Datenbank aufsetzen, vielleicht auch mehr, sich damit beschäftigen müssen, was für ein Isolationslabel brauche ich wirklich, was ist möglich.

[SPEAKER_00]: Und was will ich wirklich einsetzen? [SPEAKER_00]: Also glaubt, dass es schon wichtige wird für Entwickler ihnen, da mehr zu verstehen von [SPEAKER_00]: Sogar, wenn man da jetzt irgendeinen ORM verwendet, da das irgendwie im Hintergrund automatisiert sogar da ist, ist relevant. [SPEAKER_00]: Weil da wird es vielleicht sogar noch relevant, weil die ganz viele Querysemitung und Abzände unter dann noch mehr Probleme haben kann dadurch.

[SPEAKER_00]: Also auch diese Schicht nimmt mir das nicht automatisch irgendwie weg, da sind mir Gedanken darüber, wie machen gute Schema, was in meine Constrains und wie arbeite ich, wenn ihr Transaktionen aufmache und dann beklicht daten Ende re auch in der Datenbank.

[SPEAKER_01]: Du würfst ein interessanten Punkt auf, wenn er sollte, sich dann mit den Transaktionslevelen und mit den Isolationsmodellen und den Konsistenzmodellen meine Gütfliefe basförtagge hierher wieder durch Mikrofliegen, wer sollte sich in damit beschäftigen? [SPEAKER_01]: Du saß gerade klar, der DBR ist ausstärmt. [SPEAKER_01]: Der Systematministerator oder die Opspersonen.

[SPEAKER_01]: hat wahrscheinlich genug damit zu tun, die Datenwagen am Leben zu halten und zu abdäden und zu skalieren. [SPEAKER_00]: Ja, aber es ist ja jetzt nicht so schwer, also es gibt die vier Isolationslabbers. [SPEAKER_00]: Read Uncommitet, Read Committed, Read Repetable Read und Siri Leisever.

[SPEAKER_00]: Also es ist ja nicht, dass man da 20 verschiedene Modelle sich ansehen muss, sondern so ein Grundverständnis, dass man einfach hat und dass man weiß, wenn man mit kritische Daten arbeitet, dass man sich mal überlegt, schreiben da mehrere User mehrere Sessions auf die selben Daten. [SPEAKER_00]: gibt es der Überprobleme. [SPEAKER_00]: Und dann kann man sich ja mal Kopf zu brechen und sich überlegen, okay, könnten wir der Transaktionel verwenden, müssen wir was ändern.

[SPEAKER_00]: Und dann kann man sich ja auch entweder Hilfe holen oder andere Leute, die sich besser auskennen.

[SPEAKER_00]: Also sie sind nicht so, dass jeder, wie es ins kleinste Deil und verstehen muss, was in Microsoft Konkarency Control ist. [SPEAKER_00]: Und wie das ... [SPEAKER_00]: Implementiert wird und welche Spellen da gesetzt werden und ob dann optimistisches Locking dahinter steht oder nicht. [SPEAKER_00]: Also, das sind ja Dinge, die sind zwar ganz nett und die cool, wenn man sie versteht, aber die braucht es noch nicht.

[SPEAKER_00]: Das sehen einfach mal grundsätzlich weiß, welche dieser vier Isolationslevels brauchte ich. [SPEAKER_00]: Deswegen sagen sie, es gibt sie überhaupt, es wäre schon mal einen Grund. [SPEAKER_00]: Grundverständnis, das man haben könnte. [SPEAKER_00]: Und wenn man sich mit denen mal beschäftigt, mit den Fieren und sich das überlegt, ist man glaube ich auch in einem guten Punkt.

[SPEAKER_00]: Und das würde ich sagen, ist schon die Aufgabe von jeder Entwickler in sich das mal zu überlegen. [SPEAKER_00]: Es kann ja auch sein, dass man sagt, okay, meine Daten sind eh komplette Gahl, die ich mir alle segale Scheißer auf diese Isolationslevels brauchen nicht. [SPEAKER_00]: Es ist auch fair, aber dann hat man sich wenigstens das überlegt.

[SPEAKER_01]: Während du hier das so ganz einfach simplifizierst, ich habe ja mir nur viel Isolationsmodell und das sollte eigentlich jeder wissen und wenn du das nicht weiß, so solltest du das jetzt wissen, beziehungsweise, der jetzt mal beibringt, bin ich einfach mal auf die Webseite von Jepsen gegangen, der das natürlich dokumentiert hat. [SPEAKER_01]: Und siehe da, ich habe eine Seite gefunden über Konsistenzmodell und siehe da, ich habe mal durchgeziert.

[SPEAKER_00]: Aber bitte vor, ich kenne die Seite natürlich auch. [SPEAKER_00]: Ich habe 16 Konsistenz von der Region gefunden. [SPEAKER_00]: Die kannst du ja in die Anwenden als Postgres hat, eigentlich überab nur 3, dass sie überzbestet, der kannst du zu erfiert definieren, aber diese eine wird gemäbt aufs andere, also es gibt nur 3, meist Quälle hat 4, ist schön, wenn Chapsen die hat. [SPEAKER_00]: Und die sind sehr viel in der Theorie natürlich auch.

[SPEAKER_00]: Und was möglich ist, aber eigentlich musst du dich mit deiner Datenbank beschäftigen, was gibt's grob, drei, vier Modelle, was brauche ich. [SPEAKER_00]: Und zu 90 Prozent, [SPEAKER_00]: wird man wahrscheinlich entscheiden, ich brauche keine extremen Isolationslevels. [SPEAKER_00]: Und diesen Gedankenprozess, um den geht's. [SPEAKER_00]: Du musst nicht alles verstehen, du musst mal überlegen, gibts wo woblehme und dem Fall der kannst du dann immer noch weiter springen.

[SPEAKER_01]: Ich will darf sich natürlich nicht nur auf deine zwei, drei Datenbanken da beschränken. [SPEAKER_01]: aber ein Punkt muss man die lassen, die erste Sache ist als graf aufgebaut, das bedeutet zum Beispiel Read-An-Kommitted ist ein Kind von Read-Kommitted und zur Weiter- und sofort, ja, also ich mein kennt man das eine, kennt man so fast das andere oder also zu ab, du hast schon Punkt.

[SPEAKER_01]: Was ich aber sagen möchte, schaut doch mal, falls Sie diese Episode gar nicht im Auto hört, schaut doch mal in die Shownotes und geht doch damals auf der Konsistenz-Model link von Japsen sehr interessant, da findet ja auch die Phänomene, wie zum Beispiel einen Aborted Read oder einen Write-View oder ähnliches und dann mit diesen komischen Buchstaben ja, hier penulissen Dirty Ride und so weiter uns.

[SPEAKER_01]: Interessant, wie gesagt, es klanzert hier, macht das nicht an anderem Stach morgen, wenn ihr zuvor auf einem Geburtstag wartet, in einem SM-4 um morgens nach Hause gekommen seid, weil sich nicht, wenn ihr das Stach versteht soll, ich verspeckt.

[SPEAKER_01]: Und wenn ihr von diesem Team nicht genug bekommt und die haben uns das allererstemal eingeschaltet, haben wir ein paar andere Folgen noch für euch, wie zum Beispiel Episode 19, nach mal mal einen Datenbank, die daiv gemacht von Redis über Klick aus. [SPEAKER_01]: bis ganz krass schrelationalen Datenbangen. [SPEAKER_01]: In Episode 22 haben wir ziemlich viel über Noes, Kuell über S-It-Base und Kogesprochen.

[SPEAKER_01]: In Episode 91 haben wir das Kaptheorie mal auseinandergenommen. [SPEAKER_01]: Ein paar Datenbank folgen hatten wir schon mal deswegen einfach mal durch unser Podcast Episode Portfolio scrollen und da wältet ihr bestimmt finde ich. [SPEAKER_01]: Aber worfrag´. [SPEAKER_01]: Zum Ende dieser Episode habe ich dir noch zwei Witzer versprochen, die man nur versteht, wenn man dir zugeadet. [SPEAKER_01]: Und ich bin gespannt, ob ich sie überhaupt verstehe.

[SPEAKER_01]: Warum vertrauen Entwicklerinnen Siri-Laisable mehr als Read-Ancommitet? [SPEAKER_01]: Weil Siri-Laisable keine schmutzigen Geschichten verbreitet. [SPEAKER_01]: Ja, ich gibt Zutel auf Engelschweiler besser mit den Dirty Reads. [SPEAKER_01]: Ja, schauen wir mal. [SPEAKER_01]: Ja, ja, ja, ja. [SPEAKER_01]: Oder find ich auch ganz schön. [SPEAKER_01]: Warum sind Base-Daten Banken schlechte Freunde? [SPEAKER_01]: Sie sind zwar verfügbar, aber du kannst ihn nicht immer vertrauen.

[SPEAKER_01]: Ja, denn wenn sie das entschlägt. [SPEAKER_01]: Also, ich fand ihn nicht schlecht, wenn man eben schnell in gentim bediegeneriert, muss ich zugeben, er gab schon mal schlechterer Witzer. [SPEAKER_01]: Chipitiv wird auch immer besser im Flachwitzigenerien. [SPEAKER_01]: Na ja, so zugegeben, ich habe zur Vorbereitung schon noch ein bisschen mit der Erum gespielt, weil ich bin ja auch kein Gott in diesem Thema. [SPEAKER_01]: Also da waren schon ein bisschen Promthistorie dabei.

[SPEAKER_01]: Und ich habe mich auch ein paar Ägypten Sachen durchgelesen und dann kommt ChatGPT auf sowas. [SPEAKER_01]: Und wenn du uns immer noch zuhörst und uns einen gefallen tun möchtest, da würde ich sagen, teile diese Episode mit einem Systemadministrator Operations-Pel, mit einer Operations-Person oder oder oder. [SPEAKER_01]: Und was mich auch interessieren würde.

[SPEAKER_00]: Super, ich sag, ob dieser Job vom DBatmen stirbt aus, sagst du, die Episode sollte an die weitergeleitet werden. [SPEAKER_01]: Na ja, also es gibt auch Leute, die sagen Cobaltprogramm ihrer Stärm aus. [SPEAKER_01]: Und ich glaube, die haben eine höchste Stunde, das von allen Programmieren. [SPEAKER_01]: Von daher würde ich sagen, vielleicht ist das auch eine Jobempfehlung, die wir dazu werden. [SPEAKER_01]: Ja, du darfst nicht immer nur Probleme sehen, Wolfgang.

[SPEAKER_01]: Du musst Möglichkeiten und Chance sehen. [SPEAKER_00]: Positives denken. [SPEAKER_00]: Siehe vor allem die Chancen für Entwickler innen, wenn sie auch mehr von Datenbracken verstehen. [SPEAKER_01]: Das ist sowieso, dann wäre die Welt besser, welches Verstand. [SPEAKER_01]: Vielen Dank fürs Zuhören und falls Summa in so einen räckigen Back, ha ha dreckigen Back, dirty read, ha ha ha. [SPEAKER_01]: Glauben bis, komm noch mal in unsere Disco-Communität und Teile uns den Back mit.

[SPEAKER_01]: Geteil des Leites halbes Leit so zu sagen. [SPEAKER_01]: Ich freue mich auf deine Story und wir hören uns nächste Woche wieder. [SPEAKER_01]: Danke Wolfgang für diese leereiche Stunde. [SPEAKER_01]: Das Problem ist, ich kann jetzt keine Datenbank mehr nutzen, ohne erst mal Konsistenzmodelle Datenbank zu googeln. [SPEAKER_01]: Und wie dokumentation dazu lesen, wo ich es im Endeffekt wahrscheinlich nicht brauchen werde, da ich nicht bei einer Bank oder Versicherung arbeiten werde.

[SPEAKER_01]: Nun gut, trotzdem danke. [SPEAKER_01]: Wir hören uns nächste mal. [SPEAKER_01]: Bis bald, bye bye.