#129 Simplify Your Stack: Files statt Datenbanken!

Vergiss Datenbanken - Benutze mehr Files!

Warum denkst du eigentlich, dass du eine Datenbank brauchst?

Würde deine Applikationskomplexität nicht deutlich niedriger sein, wenn du alles in einer Datei abspeichern würdest? Hast du wirklich so dynamische Daten? Liest du deine Daten nicht deutlich öfter, als dass du diese schreibst? Und macht die Datenbank deine Applikation nicht langsamer?

Mit dieser steilen These kommt Wolfgang um die Ecke. Obwohl dies gegen alles geht, was wir sonst normalerweise so lernen und beigebracht bekommen. Und das von jemandem, der in dem Bereich Datenbanken studiert hat. Darum geht es in dieser Episode.

Bonus: 1 Jahr Engineering Kiosk Alps Meetup.

**** Diese Episode wird gesponsert von WeAreDevelopers World Congress

Nimm am WeAreDevelopers World Congress teil, der weltweit führenden Veranstaltung für Entwickler*innen vom 17. bis 19. Juli 2024 in Berlin. WeAreDevelopers begrüßt 15.000+ Entwickler*innen und 500+ Speaker zu einem unvergesslichen Event in diesem Sommer. Nutze unseren exklusiven Rabattcode "WWC_EngineeringKiosk15" für 15% Rabatt.

Zu den Speakern gehören: Scott Hanselman, Scott Farquhar, Douglas Crockford, Thomas Dohmke, Demetris Cheatham, John & Brenda Romero, Prashanth Chandrasekar, Madona Wambua, Jonas Andrulis, Denis Yarats, Scott Chacon und viele mehr!

Mehr Infos unter https://worldcongress.dev/

Hier geht es zum Gewinnspiel: https://www.linkedin.com/feed/update/urn:li:share:7211263176640729088/

****

Das schnelle Feedback zur Episode:

👍 (top) 👎 (geht so)

Sprungmarken

(00:00:00) Happy Birthday zu 1 Jahr Engineering Kiosk Meetup Alps

(00:03:05) Gewinnspiel WeAreDevelopers World Congress

(00:04:19) Happy Birthday zu 1 Jahr Engineering Kiosk Meetup Alps

(00:13:19) Migrationen, Deployments und Schema-Versionierung

(00:20:17) tailscale, sqlite, JSON-Files und etcd

(00:27:00) Files sind schneller als Datenbanken

(00:30:56) Mehrdimensionale Daten und Relationen

(00:35:34) Schreibzugriffe und Schema-Sicherheit

(00:39:56) Performance-Overhead, Files zu parsen

(00:47:49) File as a Service und sqlite

(00:54:04) Das schlechte Gefühl, ein Junior zu sein

Hosts

Wolfgang Gassler (https://mastodon.social/@woolf)
Andy Grunwald (https://twitter.com/andygrunwald)

Feedback

EngKiosk Community: https://engineeringkiosk.dev/join-discord
Buy us a coffee: https://engineeringkiosk.dev/kaffee
Email: stehtisch@engineeringkiosk.dev
LinkedIn: https://www.linkedin.com/company/engineering-kiosk/
Mastodon: https://podcasts.social/@engkiosk
Twitter: https://twitter.com/EngKiosk

Transkript

Das Transkript wurde automatisiert per Speech-to-Text erstellt und kann daher Fehler enthalten.

Andy Grunwald (00:00:04 - 00:00:50)

Willkommen zu einer neuen Episode vom Engineering Kiosk. Diesmal kommt der Wolfgang mit einer steilen these um die Ecke. Vergiss Datenbanken, benutze mehr Dateien. Dabei lehnt er sich aus dem Fenster und sagt, dass sehr oft Datenbanken einfach nur eingesetzt werden des Datenbankseins wegen. Viele Projekte bräuchten die Komplexität einer Datenbank gar nicht. Und als wäre das noch nicht genug, sagt er auch noch, dass Files viel performanter sind. Irgendwie geht das genau gegen alles, was man so beigebracht bekommt. Und das alles von jemandem, der einen Dr. Im Bereich Datenbanken hat. Das macht mich irgendwie neugierig. Wir springen also direkt rein. Los geht's. Lieber Wolfgang, als Veteran zum Junior möchte ich dir einmal.

Wolfi Gassler (00:00:50 - 00:00:53)

Moment, Moment, was? Als Veteran zum Junior.

Andy Grunwald (00:00:53 - 00:01:25)

Ja, lass mich ausreden. Möchte ich dir gratulieren und zwar zu einem Jahr Meetup. Und wenn ich das richtig gesehen habe, habt ihr nur einmal einen Monat verpasst, und zwar den August 23. Ansonsten habt ihr jetzt eigentlich ein Jahr durchgezogen. Und die Gratulation gilt natürlich nicht nur dir, weil du machst das natürlich nicht alleine, sondern auch die Gratulation gilt auch dem Tim, dem Romedius und dem Christoph. Also Glückwunsch zum einjährigen Engineering Kiosk Alps Meetup.

Wolfi Gassler (00:01:25 - 00:01:26)

Vielen, vielen Dank.

Andy Grunwald (00:01:27 - 00:02:08)

Für Leute, die uns noch nicht so lange hören, warum bin ich ein Veteran? Ich habe seit 11 Jahren ein lokales Meetup in Düsseldorf betrieben, betreib es nicht mehr. Ich habe es Anfang 2024 abgegeben und auch einen total tollen Organisator, der das gerade weiterführt. Deswegen wollte ich dich mal fragen, weil wir im Wolfgang natürlich auch ziemlich viel über Meetups, Konferenzen, Knowledge Sharing Formate, Community Mentoring, Public Speaking hatten wir auch schon eine Episode zu sprechen. Wie fühlt sich das an, ein Jahr Mieter zu machen? Was sind so deine ein Jahr Learnings? Also z.b. welche Annahmen hattest du am Anfang, die jetzt, wo du sagen würdest, die waren falsch? Und was denkst du, hast du von Anfang an richtig gemacht?

Wolfi Gassler (00:02:08 - 00:03:04)

Ja, ich habe natürlich ganz viel richtig gemacht, weil ich von dir so viel Input hatte und so viel Erfahrung schon von Düsseldorf natürlich. Da haben wir alles perfekt gemacht, aber im Großen und Ganzen hat es gut funktioniert, dass wir schon sehr vorbereitet waren und auch gewisse Learnings aus Düsseldorf mit übernehmen haben können. Das war schon sehr hilfreich, muss man sagen. Auch so Dokumente oder so zur Vorbereitung an die Location Hosts, was die machen müssen, auf was wir achten müssen. Solche Dinge waren schon sehr praktisch und ist auch super, wenn man die einfach irgendwo niederschreibt, weil dann muss man die nicht jedes Mal kommunizieren. Und wenn man irgendwo ein Input bekommt, schreibt man die wieder in die Dokumente rein. Das kann man an die Speaker aussenden, an die Location Hosts. Also die Organisation im Hintergrund wird da stark vereinfacht. Was ich mir nicht erwartet habe, ist der große Zustrom. Wir haben recht gut gestartet mit 40 Leuten. Bei diesem Meetup hatten wir so viele wie noch nie mit 60 Leuten. Ist vielleicht auch am guten Essen von unserem Location Host gelegen in dem Fall.

Andy Grunwald (00:03:04 - 00:03:10)

Darf ich kurz fragen, wie viel Konkurrenz ihr in Tirol, beziehungsweise in Innsbruck generell habt?

Wolfi Gassler (00:04:24 - 00:04:57)

Sehr wenig. Also im tech Sektor eigentlich kaum. Es gibt eine Geschichte, die von der Native Cloud Foundation in der Scope abläuft, aber die ist viel seltener. Also wir sind eigentlich das einzige tech Meetup, würde ich mal sagen. Leider muss man auch dazu sagen, ich wäre froh, wenn es mehr gäbe, aber richtige Konkurrenz haben wir aktuell keine. Ich glaube, die größte Konkurrenz ist einfach die Sonne, gemütlichen Bier irgendwo am Inn am Fluss trinken oder Fußball schauen, wie es dieses Mal war. Das ist, glaube ich, die größte Konkurrenz, die Zeit.

Andy Grunwald (00:04:57 - 00:05:13)

Was ist denn der eine Punkt, den du dir deutlich leichter vorgestellt hast, wo du gesagt hast, mache ich mit links und da, wo du dich jetzt ein bisschen umstellen müsstest, also dein reales, ein bisschen negatives Learning, vielleicht auch positives, weil das ist das ja, was Leute hören wollen, was wirkliche Erfahrungen ausmacht, wo man wirklich mal was zu mitnimmt.

Wolfi Gassler (00:05:13 - 00:06:35)

Klingt jetzt vielleicht komisch, dass ich da gar nichts richtig habe, vielleicht auch, weil ich eben viel Kontakt auch in Düsseldorf mit mit einem Meetup hatte und da natürlich Einblick auch genossen habe schon und so Probleme gekannt habe. Vielleicht was am schwierigsten einfach immer noch ist, sind die Locations bei uns, weil wir keine Maße an großen Unternehmen haben, die den Raum sponsern, können die einfach sagen, wir haben den Raum für 60 Leute. Also das gibt es in Innsbruck kaum. Das ist eigentlich die Schwierigkeit. Und da immer zu wechseln, damit wir nicht im selben Raum sind und eben auch einem Raum, der eine Firma zugeordnet ist, einer tech Firma, das sind eigentlich die größten Probleme, weil die kleinen Startups würden zwar gerne, aber die haben halt selten den Raum für 60 Leute. Du brauchst einfach eine gewisse Größe, damit du überhaupt so einen Raum zur Verfügung stellen kannst. Und das ist eigentlich das größte Problem, die Locations immer zu finden. Also das ist schon sehr viel E Mail schreiben, mit Leute Kontakt halten, immer wieder nachfragen und so weiter. Umso mehr freut mich, dass wir bisher die Locations gefunden haben und dass so viele Firmen mitwirken und daran auch Spaß haben und wirklich mit Herzblut dahinter stecken. Also beim letzten Meetup, wo wir wieder waren, ist ein Investor, der da persönlich kocht, die die die zwei Investoren und möglichst gutes Essen vorbereiten, damit sich alle wohlfühlen. Also da merkt man schon, dass da viel Herzblut reinfliesst und nicht nur ein XY Catering bestellt wird.

Andy Grunwald (00:06:35 - 00:07:33)

Ich sage nochmal nochmal vielen Dank auch im Namen der ganzen Community, dass ihr das macht. Und falls ihr mal in Innsbruck seid oder in Tirol wandern, dann oder vielleicht das zumindest vorhabt, schaut doch mal auf Engineering Kiosk Dev Meetup. Da seht ihr nämlich die vorläufigen Daten für das komplette Jahr und vielleicht wollt ihr euren Wanderurlaub schönen, Tirol z.B. im Stubaital, das ist ganz in der Nähe, um einer dieser Daten legen, um Wolfgang, Tim, Romedius oder Christoph mal kennenzulernen und den einfach mal die Hände zu stellen und sagen danke dafür. Aber du hast mir vor kurzem etwas von einem der letzten Meetups erzählt. Und zwar hast du was spannendes gelernt bzw. Verfolgt, denn du machst das Meetup auch, um etwas Neues zu lernen und um ein bisschen netzwerken zu können und vielleicht auch mal andere Meinungen zu hören oder zu challengen. Und das war so die Tage. Erzähl mir bitte mehr.

Wolfi Gassler (00:07:33 - 00:08:33)

Ja, also gar keine Ahnung, ob es so challenging für mich war, aber für die Community auf jeden Fall, weil wir hatten beim letzten Meetup einen Talk von Daniel Walter, der war SRE bei Google und hat über Deployments gesprochen und während dem Vortrag, er hat so gesagt ja, kann jederzeit Fragen gestellt werden und so weiter. Und während dem Vortrag hat er mal erwähnt, dass er der Meinung ist, dass man viel seltener Datenbanken verwenden sollte und dass Datenbanken eigentlich ziemliche Probleme bereiten in der ganzen Deployment Pipeline und für SREs, das war dann so der Trigger, wo die gesamte Community und irgendwie plötzlich alle mitfragen und was er dazu meint. Und das hat irgendwie sehr vielen Leuten nicht gefallen. Auch in der Pause dann sind Leute zu mir gekommen bzw. Nach dem Meetup haben so gemeint Hey Wolfi, was meinst du als Datenbank zu dem Ganzen? Und haben sich das als Support erwartet von mir. Ich habe sie dann enttäuschen müssen, weil ich habe ja vor einigen Jahren selber einen Vortrag gehalten forget databases use files und ich bin eigentlich auch der Meinung, dass man viel zu oft Datenbanken verwendet.

Andy Grunwald (00:08:33 - 00:08:51)

Kannst du mich aber mal ganz kurz abholen, was heißt das? Datenbanken machen immer Probleme beim Deployment? Also ich frage mich gerade, wie ist denn meine Datenbank überhaupt jetzt gerade mit dem Deployment? Also wie steht das in Verbindung? Weil ich habe ja einen Code von einer Applikation und ich möchte ja in der Regel eine neue Applikation schieben und nicht in der Regel eine neue Datenbank.

Wolfi Gassler (00:08:51 - 00:11:15)

Ich glaube, das ist genau das Problem eigentlich damit, weil die Datenbank ja persistent ist und irgendwo anders lebt und du die Datenbank nicht so klassisch wie ein Code einfach schippen kannst. Der Code, den shipst du, der läuft irgendwo und alles was im Code ist, wird upgedatet und läuft dann in der neuen Version auf einem Server. Also das ist sehr schnell erledigt. Die Datenbank läuft woanders, die Datenbank hat ein Schema, ist abhängig von deinem Code oder der Code ist abhängig von einem Schema oder du musst dann Migrations fahren, du musst die Datenbank betreiben, du weißt nicht, in welchem State die Datenbank ist. Also die Datenbank ist noch mal ein großer Aufwand, der parallel läuft bei jedem Update, bei einem Deployment, vor allem, wenn du die Datenbank updaten musst. Also die macht deine gesamte Architektur komplexer. Und da stellt sich natürlich immer die Frage, brauchst du wirklich die Datenbank? Weil meine Erfahrung ist ja, und die habt ihr sehr, sehr oft erlebt in Developer Teams, du besprichst so eine Architektur, wie willst du irgendwas bauen zu einem Beginn von dem Projekt? Und dann kommen so die Team Member und sagen, ja, wir verwenden die und die Sprache, JavaScript und vielleicht serverseitig, clientseitig, was verwenden wir? Und dann kommt man irgendwie so an den Punkt, wo es dann heißt, ja, wir haben da keine Ahnung, irgendwie ein Config File oder wir brauchen da irgendwelche Mapping Daten für eine API. Und sobald da irgendwo Daten im Spiel sind, heißt es sofort Datenbank. Wir machen eine Datenbank, wir verwenden Redis, wir verwenden MySQL, gar kein Problem, ist ja easy, super schnell deployed, docker compose, braucht man nur MySQL einbinden, bam, alles da. Und später kommt man dann vielleicht erst drauf, was man sich da eigentlich eingekauft hat an Komplexität, obwohl man nur ein kleines File mit Mappings, lass es auch Mappings sein, wo man irgendwelche IDs mappt für APIs oder für irgendeinen internen Ablauf, wie schnell man da eigentlich zu einer Datenbank greift, obwohl das gar kein klassischer Anwendungsfall ist, wo man sagt, Okay, ich brauche eine Datenbank, ich brauche acid properties, ich speichere da ganz viel rein, lese viel, habe parallelen Zugriff, also diese ganzen klassischen Datenbank Patterns, die man oft gar nicht hat bei irgendwelchen Config Values. Aber wie oft hast du schon erlebt, dass man einfach config values mal schnell in eine Datenbank speichert, weil man sagt, ja, da kommt noch ein config value dazu und dann kann man das fein irgendwie mit SQL ändern. Und es ist ja viel viel besser das in die Datenbank speichert oder Redis, deine Lieblingsdatenbank unter Anführungszeichen.

Andy Grunwald (00:11:15 - 00:11:26)

Also sagst du mir jetzt eigentlich, es ist nicht das Problem, dass wir eine Datenbank haben beim Deployment, sondern eigentlich, dass wir die Datenbank beim Deployment nicht mit deployen.

Wolfi Gassler (00:11:26 - 00:11:36)

Ja, das Problem ist ja weniger die Datenbank an sich, sondern den State der Datenbank. Also der läuft ja parallel, du kannst den nicht überschreiben in dem Sinne, oder? Ist viel, viel schwieriger.

Andy Grunwald (00:11:36 - 00:11:45)

Reden wir hier vom State in der Datenbank oder reden wir hier davon, das was die Applikation erwartet, das Schema, die Tabellennamen, die Felder und so weiter und so fort.

Wolfi Gassler (00:11:46 - 00:13:19)

Ja, nehmen wir mal ein ganz einfaches Beispiel. Also klar, es gibt sicher Szenarien, wo man Datenbanken ganz klar braucht, aber bleiben wir mal bei einem Szenario. Du machst irgendeinen Service, der Service spricht mit APIs und du brauchst irgendwelche Informationen, welche ids du verwalten kannst oder ansprechen kannst oder einfach eine lange Liste von von IDs oder von barconfig werten 1 Million. Dann werden ganz viele Leute das in der Datenbank speichern, weil sie sagen, ich habe dort Daten, die ändern sich ja hin und wieder. Irgendeine ID kommt dazu, irgendwas ändert sich. Das heißt, ich kann dann insert ein Update machen und dann habe das in der Datenbank. Wenn du jetzt Code deployst, kannst du nicht direkt Dinge in der Datenbank ändern. Also wenn jetzt fünf IDs dazukommen in deiner Datenbank oder fünf config Values, dann kannst du die nicht in deinen Code mit deployen. Also du hast Migrations, was wieder ein großer Aufwand ist, also Migration Framework, das dir die Daten, die du im Code hast, dann in die Datenbank speicherst. Jetzt, wenn du deine Applikation ausrollst, wann speicherst du deine neuen IDs in die Datenbank? Wie machst du das? Machst du das manuell? Machst du das in dem Prozess? Also wie läuft es ab? Und da merkt man schon, du hast plötzlich nicht mehr einen Deployment Prozess, sondern mehrere Deployment Prozesse, auch für die Datenbank, für den Inhalt der Datenbank, vielleicht ein Cron Job, der jede Nacht läuft, auf jeden Fall zusätzlich irgendwas. Und du hast nicht mehr nur den simplen einen Deployment Prozess von deinem Code.

Andy Grunwald (00:13:19 - 00:13:33)

Du redest jetzt also eigentlich von diesen, ich sag mal, Migrations Skripten, diese One of Dinger, die ich einmal schreibe, um von der alten Version auf die neue zu wechseln, die dann mal ausgeführt werden müssen, damit die Daten, weiß ich nicht, im neuen State sind oder ähnliches.

Wolfi Gassler (00:13:33 - 00:14:15)

Wenn du eine Schema Änderung hast, ja, aber es kann ja auch einfach sein, dass du irgendwas änderst von den Inhalten, also von den Daten an sich, da musst du auch schon dir überlegen, klar kannst du es manuell machen mit einem Skript, mit einem Cron Job innerhalb von der Deployment Pipeline kannst du das natürlich auch irgendwie machen mit Migration, aber du merkst schon, du musst überlegen, du musst nachdenken, wie mache ich das, wie kann ich das dort reinbringen, wie funktioniert das überhaupt? Also da merkt man ja schon, dass man einfach viel mehr sich Gedanken machen muss, wie man die Daten in die Datenbank bringt. Und da sprechen wir noch gar nicht vom Betrieb der Datenbank, der natürlich nochmal ein eigenes Thema ist, Monitoring und so weiter.

Andy Grunwald (00:14:16 - 00:15:02)

Ich würde fast sagen, diese Einmaländerung, das ist ein gelöstes Problem oft. Du hast ja auch schon von diesen Frameworks gesprochen, von diesen Datenbank Versionierungsframeworks, da wo ich dann schämen mein Schema und mit dem Migration Step auch versioniere. Ich glaube, Capistrano früher von Ruby on Rails konnte das auch. Und da gibt es Liqui Base und Visa, alle heißen. Wo ich mir aber gerade so ein bisschen Kopf zerbreche, ist bei den möglichen Rollback Szenarios, weil es gibt ja natürlich auch die Strategie, die ich auch sehr, sehr oft anwende, bin ich auch ehrlich, fail forward, wir fixen, wir rollen nicht zurück, wir gehen nur nach vorne. Geht sehr, sehr oft sehr gut. Und deswegen, weil Rollbacks einfach schwierig sind. Aber du erzählst mir gerade die Komplexität vom Deployment, aber ist die reale Komplexität nicht beim Rollback?

Wolfi Gassler (00:15:02 - 00:16:56)

Ist natürlich auch eine Komplexität und das ist der Vorteil, wenn du es schaffst, um jetzt gleich mal die Alternative aufzu und gleich mal die Alternative überhaupt zu erwähnen, wenn du es schaffst, deine Config Files, deine ID Mappings, was du da halt so brauchst, die sich selten ändern durch irgendeinen, keine Ahnung, wöchentlichen Prozess oder monatlichen Prozess oder teilweise, ich hatte so ein Beispiel eben, da ist es um Mappings gegangen, ja, da ist hin und wieder mal eine ID dazu gekommen, aber das war mehr so alle zwei, drei Monate oder in den ersten drei Monaten hatten wir gar nie eine Änderung, aber beim Planen hatten wir natürlich schon im Kopf, wenn sich das ändert, wenn da viele Änderungen kommen. Und dann haben wir schlussendlich einfach diese Daten genommen, in Beispiel JSON File gepackt und haben dann die Daten einfach beim Start immer in den Hauptspeicher eingelesen. Das heißt keine Datenbank, sondern die Applikation hat einfach diese Werte einmal zu Beginn eingelesen, die sind in nullkommanichts drinnen im Hauptspeicher, du kannst sie superschnell ansprechen, du hast keinen Overhead durch SQL oder ähnliche Dinge. Und dann, wenn du das natürlich über so ein File machst, über einen ganz klassischen Import Prozess, dann ist natürlich Rollback super easy, weil du gehst auf die alte docker Version zurück, also Docker Image Version und hast damit auch wieder die alten Daten. Also da hast du deine Daten direkt im Git verknüpft mit deinem Code und näher geht es ja gar nicht. Und dann hast du eigentlich diese Reproducibility in deinen Code hineingebacken. Und wenn du das erreichen kannst, dann ist es natürlich super easy, das Ganze zu handeln. Und diesen Vorteil erreicht man natürlich, wenn man nicht von Anfang an sofort auf eine Datenbank setzt. Klar, geht mit einer Datenbank, wie du sagst, es ist ein gelöstes Problem, aber die Komplexität erhöht sich und die Geschwindigkeit üblicherweise würde ich mal sagen, ist in der Datenbank auch langsamer, in so einem Fall zumindest.

Andy Grunwald (00:16:56 - 00:18:08)

Aber ich meine, den Pfeil, den du gerade beschreibst, den Fall, den du natürlich gerade beschreibst, sorry, das war ein Wortspiel, was nicht gewollt war, den kann man ja auch relativ einfach lösen, indem ich einfach Tabellen habe und dann id mapping unterstrich v, v, v und so weiter. Und dieses v ist dann vielleicht auch genau die Applikationsversion. Also ich meine, da sehe ich jetzt auch keinen riesen Unterschied, weil oft hat man natürlich dann vielleicht noch so ein Content Team mit so einer Web UI, die editieren das oder wer auch immer dieses Mapping da herstellt. Es sind ja seltenst die Software Engineers selbst, sondern das kommt dann aus einem externen Team oder wird eingekauft. Und wenn man das jetzt mal weiterdenkt, denn Datenbank kann ja nicht nur fünf Tabellen haben. Und wenn du jetzt sagst, ja gut, dann habe ich so ein Tabellen Versions Wirrwarr, du kannst ja auch weitergehen, ja, MySQL z.b. kann nur ein Schema pro Datenbank haben, nehmen wir aber mal so eine Postgrad z.B. die kann einfach mehrere Datenbank Schema pro Datenbank haben. Und da wird es natürlich auch schon wieder interessant, weil du dann kannst du ja eine ähnliche Art von Versionierung sogar auf Schema Basis machen. Du hältst die anderen Schemen vor und wenn du sagst, okay, die letzten 10 Versionen, die benutze ich eh nicht mehr und dann schmeißt man die weg, oder?

Wolfi Gassler (00:18:08 - 00:20:16)

Klar, kannst du, aber einfach ist was anderes. Also genau diese Komplexität meine ich ja, die dadurch erhöht wird. Klar, du kannst alles abbilden, aber ist die Frage, ob es überhaupt nötig ist. Ich habe z.B. gerade in kleinen Projekten, also ich habe das in großen Projekten schon erlebt, dass zu schnell auf eine Datenbank oder Redis gesetzt wird, weil sobald mehr als fünf Werte braucht man eine Datenbank. So der Klassiker. Und gerade bei side Projects oder Startups, wenn man früh beginnt, wird glaube ich ganz oft der Fehler gemacht, dass man sofort auf eine Datenbank setzt, weil man wird ja groß, man wird die größte Applikation ever. Und die hatte das gerade kürzlich bei einem side Project von mir. Ich habe da so ein WhatsApp Bot geschrieben, der den Status schreiben muss von Usern. Und ich hatte auch lange die Überlegung, soll eine Datenbank verwenden, vielleicht einfach eine sqlite oder irgendwas kleines, um den State zu schreiben. Und ich habe es dann bewusst nicht gemacht und ich bin so froh bisher, weil es ist so viel einfacher. Ich schreibe einfach ganz hart dieses Jason File, weil es sind, lass es ein paar hundert Werte sein, sind es in dem Fall eh nicht. Und du kannst dieses Jason File einfach immer schreiben. Ich schreibe das, das ist speed mäßig, überhaupt kein Problem. Ich schreibe das rein. Mir ist schon klar, wenn genau in dem Moment vom Schreiben jetzt irgendwie der Host zusammenbricht, irgendein Problem ist, dann hat man ein Problem, ganz klar. Aber bei wie viel side Projects ist das ein Problem? Und ich schreibe einfach jedes mal, wenn ich eine Änderung mache, schreibe ich einfach dieses JSON File von ein paar kb raus, wird auf die Platte geschrieben, ich habe immer den State, super einfach zum Backupen. Ich kann hinten einfach die Datei wegschreiben, das kann ein s Bucket sein sogar, wo die Daten geschrieben werden. Dann hast du alle Daten sogar online und vielleicht sogar versioniert, wenn du da irgendeine cloud Version einbindest. Also einfacher geht es gar nicht. Und wenn mir da überlege, wie komplex es gewesen wäre, eine Datenbank zu machen, auch SQLite, ein Schema musst du machen, du musst definieren, wie deine Daten abgespeichert werden, du musst SQL Query schreiben. Und so hast du einfach in dem Fall dieses Node JS direkt das JSON File, hast das in Memory gemappt und hin und wieder schreibst du das einfach hinaus.

Andy Grunwald (00:20:17 - 00:23:09)

Normalerweise würde ich dir jetzt hart Contra geben, aber es gibt einen Fall, der passt genau auf die Story, die du gerade genannt hast. Und zwar gibt es die Firma Tailscale. Tailscale ist so eine Art VPN Provider, aber die sind bekannt geworden, weil die so einfach sind. Du startest einfach ein Demon und buff, hast du ein sicheres eigenes Netzwerk und so weiter. Kann man sich mal anschauen, haben wir auch in den Show Notes verlinkt. Und die haben einen schönen Blogpost geschrieben und der heißt in unlikely Database Migration. Und zwar ist, ich glaube im Jahr 2000 oder sowas Brad Fritz Patrick zu Talescale gewechselt. Das ist einer der Autoren oder der Kernautor von Memcache, die damals und der war in der Sprache Go sehr viel unterwegs bei Google, deswegen folge ich dem und deswegen bin ich auch auf diesen Blogpost irgendwann gestolpert. Auf jeden Fall hat ist der als Engineer dieser Firma gejoint und die erste Frage, die er gefragt hat, welche Datenbank nutzen wir denn? Mysql, postgresqlite, ich finde sqlite ganz cool. Welche Datenbank nutzen wir? Und hat als Anfang bekommen einen Text File. Und dann fing er an wie jetzt? Ja, wir schreiben alles in ein großes Text File und da ist nur JSON drin. Wie jetzt, hey, VPN Provider, tausende von Kunden, ja, immer wenn sich was ändert, nehmen wir uns ein Log von einem Single Process und schreiben das ganze File neu. Und dieser Blogpost geht so darum, warum ist das so? Und da hat er den Gründer mal ein bisschen gefragt. Und zwar hat er Gründer Tailscale ganz am Anfang mit einer sqlite Datenbank gestartet. Und weil sich die Anforderungen immer geändert haben, wie du sagtest, gerade ein Startup, war der konstant am Refactor, der war konstant irgendwie den Datenbankzugriff am abändern, das Schema am abändern und so weiter und so fort. Und irgendwann war der, war der so ein bisschen sick of it, da hatte da keine Lust mehr drauf, hat er gesagt, weißt du was, wenn ich jetzt hier entwickle, dann mache ich alles in Memory, dann mache ich alles mal einfach. Und dann hat er einfach so ein in Memory Modell geschrieben zum Experimentieren. Und das hat unglaublich gut funktioniert. Und irgendwann sagt ein Kunde so dieses Feature würde ich jetzt gerne nutzen. Und er war sich aber nicht wirklich sicher, jetzt kann ich das in Memory Modell eigentlich so nutzen. Und hat er das einfach gemacht, hat er das in Memory Modell kompiliert und schreibt das Ganze in eine Textdatei und hat das den Kunden rüber geschickt. Und das hat etliche Jahre für die funktioniert. Später sind sie dann auf etcd gegangen. EtcD ist ein Distributer Key Value Store, wird glaube ich auch von Kubernetes und runter genutzt. Und ganz später sind sie dann wieder von etcd wieder zurück zu sqLite. Aber, und jetzt kommt mein challenging part, weswegen ich das erzähle, der Blogpost sagt auch it is currently a single go process on a single VM, weil das wird dein WhatsApp Bot sehr wahrscheinlich auch sein, irgendwo ein einzelner Prozess auf irgendeiner Maschine. Was ich mich jetzt aber frage, hast du eine zweite Maschine? Kommt man doch schon mit deinem File Approach schon gar nicht mehr weiter oder.

Wolfi Gassler (00:23:09 - 00:26:30)

Wenn du schreibst, also lesen ist überhaupt kein Problem, wenn wir bei dem Mapping Beispiel bleiben. Du hast das Mapping hart gecodet in deinem Code drin, dann kannst du auch 10 Nodes hochbooten mit dem Code. Jeder wird die Mapping Tabelle in Memory haben bei sich auf dem jeweiligen Node, dann hast du überhaupt kein Problem und da hast du sogar extreme speed Vorteile, wenn du Dateien verwendest. Ich habe das damals eben für meine Präsentation mal probiert mit PHP sogar. Also ich habe einen Server aufgesetzt, der einmal Daten von Objekten in MySQL speichert und einmal in Dateien und zwar pro Datei ein Objekt jetzt mit einer Million und probiert. Und zwar kannst du in PHP relativ einfach immer PHP Dateien inkludieren, also in dem Fall PHP Dateien geschrieben und jede PHP Datei beinhaltet dann jeweils die Struktur, die Daten von dem jeweiligen Objekt und das wird einfach direkt hinein gemappt, also gar nicht in den Hauptspeicher geladen. Also je nachdem, das überlasst man dann PHP, aber es ist ein Include von dem PHP File und da drin liegen dann die Daten. Und das ist ja eigentlich ein ganz klassisches Szenario auch für extrem high frequency Webseiten. Also wenn du dir überlegst, du hast jetzt irgendwie eine Webseite, die Hotels anbietet, Wohnungen anbietet, irgendwelche relativ statischen Einträge, also wo nicht oft ein Eintrag dazu kommt, dann könntest du dir überlegen, alle Einträge immer in eine Datei zu schreiben auf die Platte, die liegen vielleicht sogar in der Datenbank im Hintergrund, aber du schreibst sie in dein Git in ein geshartes Network drive z.B. und kannst dann direkt auf die Daten zugreifen. Und in meinen Tests war das so, dass die Dateien ungefähr doppelt so schnell waren, wie wenn die Daten in der MySQL Datenbank liegen und ihr habt wirklich die ganzen Caches aufgewärmt, egal ob Datenbank oder falls, also beides muss man einmal aufwärmen, sonst liegen die Zeiten natürlich viel höher. Aber die Zugriffe auf meine Dateien waren z.B. 20 Millisekunden von meinen Tests, also wirklich mehrere tausende Zugriffe. Habe dann den Average genommen oder den den Mean Value 20 Millisekunden versus Datenbank 40 Millisekunden oder 46 Millisekunden sogar. Also da sind schon große Unterschiede zwischen den Herangehensweisen und da spart man sich dann das Caching, was man sonst einbaut, weil normal spricht man die Datenbank an SQL, dann überlegt man sich, ist vielleicht zu langsam, dann überlegt man sich okay, dann bauen Cache ein und was macht der Cash? Er schreibt in Dateien auf das Fallsystem. Also wenn man das im vorhinein schon so ähnlich wie ein Static Site Generator im Hintergrund generiert und dann die cache Dateien schon schreibt, dann bist du natürlich auch wesentlich bei Formanter. Also auch da wieder, wenn man ein bisschen von der anderen Seite kommt und sich einfach überlegt, wie schaffe ich das vielleicht gar nicht die dynamische Seite reinzubringen in mein Frontend, in den Code, sondern vielleicht nur irgendwo hinten in der Datenbank zu haben und dann aber statisch zu schreiben, wie ein Cache, der von außen befüllt wird, also von der anderen Richtung gedacht, dann kann ich mir natürlich da schon viel Speed auch rausholen. Und das kann auch unter Umständen sinnvoll sein für eine Webseite, die halt wirklich Millionen von Zugriffen bekommt.

Andy Grunwald (00:26:30 - 00:26:49)

Ich habe mir gerade Gedanken gemacht, wenn ich jetzt eine Datenbank habe und die Daten, die meine Applikation liest, beim Deployment Prozess raus dampfe in ein Pfeil und dann als File mit in mein Artefakt lege, eine docker Image oder ins Jar mit rein kompiliere oder ähnliches. Ist das eine cache Generierung oder ist das schon so eine Art Denormalisierung?

Wolfi Gassler (00:26:49 - 00:26:51)

Ist ja egal, wie du es nennst.

Andy Grunwald (00:26:51 - 00:26:55)

Aber eigentlich optimiert man ja dann seine Daten für die Lesezugriffe.

Wolfi Gassler (00:26:55 - 00:27:00)

Richtig, genau, aber. Aber in einer smarteren Form natürlich.

Andy Grunwald (00:27:00 - 00:27:45)

Jetzt muss ich aber mal hier sagen, du bist so ein bisschen schwierig gerade, weil du bist so ein bisschen wie die Bild Zeitung, weil die Bild Zeitung sagt nämlich auch, die würde jetzt, wenn die dir zuhören würde, Wolfgang sagt, Dateien sind schneller als Daten. Ja, also ich frage mich gerade ganz viel, welches Dateisystem hast du denn benutzt? ZFS versus Ex z.b. weil ich meine, da gibt es ja auch sehr große Unterschiede, Deduplizierung und so weiter und so fort. Dann Meine nächste Frage, wurden deine Daten eigentlich wirklich geschrieben? Weil ich meine, eine Datenbank kümmert sich ja unter anderem auch darum, zumindest viele Datenbanken, dass die den F Sync Befehl im Linux System z.B. ausführen und dann wirklich zusehen, dass der Incor State mit dem Storage Device synchronisiert wird.

Wolfi Gassler (00:27:45 - 00:28:40)

So darum, darum war ja meine Annahme am Anfang, dass es eigentlich nur mehr oder weniger read only ist, weil bei ganz vielen Projekten in der Internetwelt, wo du etwas anzeigst, hast du fast einen Read only Case und kannst vielleicht das Schreiben in irgendeiner Form anders lösen oder eben vielleicht geschrieben wird in die Datenbank, aber du renderst es dann, deduplizierst es hinaus in deine statischen Files. Und zur anderen Frage, was für ein Dateisystem, das ist ja das super interessante, das ist mir egal, weil ich habe ein Betriebssystem, was super, super optimiert ist. Die cachen im Betriebssystem, ich habe meine L bis L, keine Ahnung wie viel es schon gibt, Caches, das wird alles super gecached. Also was besseres als mein Betriebssystem cash gibt es ja fast nicht. Und das ist mir komplett egal, was für Dateisystem das ist. Und sogar wenn es ein Network Drive ist, wenn der Treiber das lokal cached, was die meisten ja auch machen, dann hast du da sogar gar kein Problem.

Andy Grunwald (00:28:40 - 00:28:44)

Jetzt ist es natürlich so, wir reden jetzt hier vom Read only Case, zumindest.

Wolfi Gassler (00:28:44 - 00:28:51)

Wenn es um große Datenmengen gehen. Im kleinen Fall kannst du auch einfach in dein JSON schreiben, wie wir gesagt haben, funktioniert auch sehr lange.

Andy Grunwald (00:28:51 - 00:29:09)

Ja, aber bei der Datenbank habe ich ja das Ding, den Riesenvorteil, ich habe eine Tabelle mit 50 Datensätzen und kann Datensätze 47 neu schreiben. Bei Dateien ist das ja alles ein bisschen schwieriger. Natürlich kann man auch Dateien öffnen und dann da auf den Bytes rumtouren und so weiter. Aber in der Regel schreibt man ja.

Wolfi Gassler (00:29:09 - 00:30:56)

Das ganze File neu oder je nachdem wie du es löst, du kannst ja auch pro Datensatz ein File machen, bist du halt dann begrenzt mit Anzahl der Files und so weiter, je nachdem was Sinn macht. Aber wie gesagt, bei wie viel Zeit Project schreibst du 10 Datensätze, weil du kommst gar nie zu dem Punkt, wo du 1 Million Datensätze hast. Und wenn du 1 Million Datensätze hast, dann bist du garantiert durch so viele Schleifen schon durchgegangen und dann kannst du ja irgendwann deine Daten verwenden. Aber wenn du mal startest, finde, ist es ganz, ganz wichtig, einfach sich zu überlegen, brauche ich in dem State jetzt wirklich eine Datenbank? Weil einführen kann in eine Datenbank immer später. Ich habe meine Schnittstellen im Code und ob da jetzt ein JSON rausgeschrieben wird am Ende oder eine Datenbank, das kann ja dann relativ schnell ändern. Aber ich kaufe mir nicht von Anfang an die Komplexität ein. Und ich habe da ein schönes Zitat auf Hacker News gefunden, können wir gerne verlinken, probiert es mal ins Deutsche zu übersetzen. Der hat irgendwie geschrieben, der Unterschied zwischen Experten und fortgeschrittenen Devs besteht darin, dass der fortgeschrittene Engineer komplexe Lösungen versteht und fälschlicherweise versucht, sie überall einzusetzen und damit die Komplexität erhöht. Und der Experte sieht typischerweise die einfachen Lösungen und probiert die Komplexität möglichst niederzuhalten, um eben die gesamte Architektur klein zu halten, Wartung niedrig zu halten und so weiter. Weil eine Datenbank zu betreiben ist ja auch nicht so einfach. Du musst monitoren, du musst backupen, du musst schauen, dass die up to date bleibt, du musst sie updaten und und und. Sogar wenn es sqlite ist, embedded ist ein bisschen anders, kannst ja embedded Datenbank fahren, aber sonst auch eine sqlite musst du in irgendeiner Form starten, betreiben, schauen, dass sie läuft. Was ist, wenn sie abstürzt? Einfach mehr Komplexität.

Andy Grunwald (00:30:56 - 00:32:31)

Ich frage mich gerade, von welcher Datentiefe wir sprechen. Also ich meine bei eindimensionalen Daten ja sowas wie Mapping und das Wort haben wir jetzt schon öfter benutzt. Mapping ist eigentlich nur Übersetzungstabelle. Du übersetzt Zahlen in Buchstaben oder andersrum. Nehmen wir mal eins für den Buchstaben A und 26 für den Buchstaben z. Das wäre jetzt ein Mapping. In der Hinsicht sowas. Ich glaube, da gibt es ganz wenige Leute, die sagen, statische Mappings read only. Macht vielleicht Sinn, diese Art von Caching oder Denormalisierung, von der wir gerade gesprochen haben, zu anzuwenden. Aber wie sieht es denn mal mit mehrdimensionalen Daten aus? Und damit meine ich jetzt nicht tief verschachtelt, sondern Relationen. Ja, weil das ist ja in der Regel der Punkt, du hast Aufträge und Kunden eins zu n. Zerbricht da dein Modell nicht relativ schnell? Weil ich meine, da bist du ja auf einmal in Memory dabei. Schon so eine Art, ich will jetzt nicht von Query Parser reden oder ähnliches, ne, aber du eröffnest mehrere Files, wenn wir es vielleicht sagen. Jeder Auftrag ist eine einzelne Datei, die ja in der Regel auch idempotent geschrieben wird. Also seltenst wird ja ein, nehmen wir mal Angebote. Angebote ist eine tolle Geschichte. Ein Angebot wird erstellt, danach kriege ich das als Kunde. Ich telefoniere dann später noch mal nach und will noch mal was justieren. In der Regel kriege ich ja dann eine geupdatete Version, eine Version zwei von diesem Angebot. Also Angebote behandeln wir jetzt eigentlich mal als idempotent und da bin ich dann bei dir. Die schreibt man einmal und liest man vielleicht mehrmals. Aber die Kundendaten, also ein Kunde kann ja mehrere Angebote haben und so weiter. Eins zu N Relation. Wie würdest du das regeln? Wie verteidigst du dein Datenmodell jetzt hier, liebe Bild Zeitung?

Wolfi Gassler (00:32:31 - 00:33:35)

Also es gibt da zwei Antworten. Die erste Antwort ist, wenn du das wirklich brauchst, nimm eine Datenbank. Das ist das, was ich in allen meinen Datenbank Vorlesungen rauf und runter bete. Die klassischen Anwendungsfälle, relationale Daten und so weiter. Aber in deinem speziellen Fall mit den Angeboten oder Rechnungen ist nämlich der Klassiker der, dass du bei einer Rechnung z.b. die Kundendaten zu dem Zeitpunkt, wo du die Rechnung erstellst, kopierst. Weil wenn du die Kundendaten in ein Jahr später änderst, den Ansprechpartner, die Straße, dann muss die Rechnung trotzdem die alte Straße beinhalten. Das heißt, du duplizierst deine Daten in dem Fall, damit du eben die alten Datenstände alle hast. Und bei den Angeboten ist es auch oft so, weil du das ja nachvollziehen musst, hat es welche Person hat es damals wirklich bekommen? Nur weil sich der Ansprechpartner ein Jahr später ändert, kann es nicht sein, dass alle Rechnungen und alle Angebote plötzlich den neuen Ansprechpartner oben haben. Also auch da ist es oft so, im Lehrbuch ist es zwar ein relationaler Ansatz, in der Realität oft nicht.

Andy Grunwald (00:33:35 - 00:33:43)

Ich hatte gedacht, ich habe dich gerade nur der Fall mit den Angeboten, da muss ich zugeben, da habe ich mich selbst ein bisschen ins Haus geschossen, aber das ist ein fairer Case.

Wolfi Gassler (00:33:43 - 00:33:57)

Aber, aber es gibt ganz viele Anwendungsfälle, da brauchst du eine Datenbank, da brauchen wir gar nicht drumherum reden. Mein Argument ist ja, dass es einfach, dass immer eine Datenbank auf die Probleme geworfen wird, ohne dass man mal überlegt, brauche ich überhaupt nicht Datenbank, jetzt höre.

Andy Grunwald (00:33:57 - 00:34:31)

Ich den Podcast und möchte ein bisschen Simplicity in meine Firma reinbringen. Ich möchte Dinge weniger komplex machen, weil ich mich wie der Hacker News Spruch gerade als erfahrenen Menschen ansehe, als erfahrener Software Ingenieur und in der Regel arbeite ich in einer Firma, die schon ein bisschen länger da ist und schon eine Datenbank da ist. Würdest du sagen, wenn die Datenbank sowieso schon da ist und all die Probleme, die du da ansprichst mit Monitoring und allem drum dran, nutzt sie einfach? Oder würdest du sagen, vielleicht macht es doch Sinn, das Mapping trotzdem in den Pfeil zu schreiben?

Wolfi Gassler (00:34:31 - 00:35:34)

Ich würde sagen, bei alten Projekten, klar, Datenbank verwenden, überall wo es geht. Wobei auch da wieder, muss man jeden config Wert in eine Datenbank speichern oder ist es im Code vielleicht doch besser aufgehalten in irgendwelchen Environment Variablen? Also die Frage stellt sich natürlich immer, aber ich kann ja auch in einer großen Firma ein neues Projekt starten und dann kann ich mir natürlich schon überlegen, macht es Sinn, die Datenbank zu verwenden oder vielleicht, weil wir immer eine Datenbank verwenden, fahren wir halt jetzt auch wieder eine Datenbank hoch. Aber gerade heutzutage wird es ja auch oft so gemacht, dass man nicht eine zentrale Datenbank hat, sondern jede Applikation hat eine eigene Datenbank oder vielleicht sogar mehrere Datenbanken für eine Applikation. Und dann stellt sich natürlich schon die Frage, muss jetzt die 48. Datenbank hochfahren in meinem Docker Composer oder kann ich mir mit einem JSON File genauso behelfen? Wie gesagt, sobald man schreiben muss, ist alles ein bisschen schwieriger und da muss man dann schon genau abwägen, macht Sinn, aber ganz oft, wenn man genau darüber nachdenkt, hat man read only fall oder zumindestens einen write ganz selten Fall.

Andy Grunwald (00:35:34 - 00:35:42)

Wie würdest du deine Datei first Architektur, File first Architektur, denn im Schreibfeil verteidigen?

Wolfi Gassler (00:35:42 - 00:37:13)

Ja, gar nicht. Wenn sie keinen Sinn macht, brauche ich sie gar nicht verteidigen. Wie gesagt, ich würde sagen, gerade am Anfang bei kleineren Projekten oder wenn nicht oft geschrieben wird, dann kann ich das schon trotzdem über einen File machen. Und wie gesagt, wenn es da irgendeinen Prozess gibt im Hintergrund, der mal Daten aus einer zentralen Datenbank liest und dann einen JSON File daraus generiert und bei jedem Deployment wird es einfach mit deployed, was ja mir dann auch noch mal Sicherheit gibt, weil ich weiß, meine Tests sind mit diesen Daten getestet worden, das läuft genau mit diesen Tests, dann wird es deployed und läuft mein Service. Hingegen, wenn dann Background Job irgendwie jede Nacht läuft und Config Values updatet oder irgendwelche Mapping Daten z.B. updatet oder inhaltliche Daten, dann kann es natürlich sein, dass plötzlich meine Applikation von heute auf morgen bricht, weil in der Datenbank irgendwelche dummen Daten stehen, die der Background Prozess oder der Cron Job in der Nacht upgedatet hat. Das kann mir natürlich nicht passieren, wenn ich immer nur die Daten verwende, die ich, wenn ich ein Deployment durchführe, mitschicke. Und das heißt, auch da habe ich wieder mehr Sicherheit gewonnen. Und wenn ich mir das leisten kann von meinem Use Case, dass ich sage, okay, ich habe nicht die letzten Daten immer online, aber die blaue sowieso alle paar Tage mal z.B. oder einmal die Woche und wenn da ein paar Daten noch nicht verfügbar sind, ist das auch okay. Dann kann es natürlich ein gangbarer Weg sein, der mir einfach viel mehr Sicherheit gibt und meine Applikationen stabiler macht und einfacher wartbar macht.

Andy Grunwald (00:37:13 - 00:38:08)

Auf der anderen Seite, durch so ein Datenbankschema hat man auch eine ganze Menge Sicherheit. Also ich meine, wenn ich jetzt ein JSON Objekt habe oder eine Liste von JSON Objekten, JSON Objekten, das ist auch so doppelt gemoppelt, JavaScript Object Notation, JSON Object, naja, dann ist es ja auch so, dass ich doch eigentlich bei jedem Pfeil zugriff, also ich öffne das Pfeil, dann muss ich das auch erstmal durch ein JSON Schema validieren, weil diese Sicherheit, dass das Pfeil in dem Format so vorliegt, wie ich das von meiner Applikation erwarte, ist ja nicht unbedingt gegeben, oder? Ich meine, da habe ich dann noch die ähnliche, ich sag mal langsame Problematik wie eine Datenbank, wo die Datenbank einen Query Parser hat und sagt, okay, gibt es dieses Feld, was du hier abfragst, so muss ich das doch eigentlich auch beim Pfeil öffnen gegen einen XML Schema Validator. JSON Schema Validator, Protobuff oder ja, was in was mein File auch immer ist, muss ich ja eigentlich auch tun, oder?

Wolfi Gassler (00:38:09 - 00:39:56)

Natürlich, klar. Aber das ist auch so ein bisschen ein Lehrbuch Argument, dass die Datenbank mir die Sicherheit gibt, weil die Datenbank gibt mir natürlich nur die Sicherheit, wenn ihr das Schema ganz genau definieren kann und auch gemacht habe und nicht alles in String Speicher und dann kann String auch leer sein, ist er dann null oder ist er leer? Oder wenn da irgendein Wert reingeschrieben worden ist, der nicht meiner Spezifikation entspricht, kann ich das in der Datenbank überhaupt checken? Und da ist halt die Frage, wie viele Applikationen schreiben in die Datenbank? Das ist halt so ein klassischer Fall, der kommt aus der Zeit, wo es eine zentrale Datenbank gibt und 18 verschiedene Prozesse schreiben in diese Datenbank. Wenn ich aber der einzige Prozess bin, der in die Datenbank schreibt, dann wird höchstwahrscheinlich auch das Schema passen und der Inhalt passen. Und wenn ich irgendwo ein Blödsinn schreibe, einen leeren String z.B. den schreibe ich in JSON, aber auch in die Datenbank. Also wenn das ein Problem für mich ist, dann weiß auf beide Seiten haben. Klar habe ich keine harte Validierung, wenn ich sie nicht zusätzlich einbaue, aber auch da wieder kleine Projekte, side Projects, wer baut da große Validierungen schon ein und wie viel Datenbankschemien gibt es, wo eh alles mehr oder weniger String ist oder in sqlite ist sowieso alles ein String. Also das macht es dann auch nicht unbedingt einfacher. Also das Argument würde ich sagen, klar, alte Applikationen, große Applikationen, viele verschiedene Applikationen, die schreiben ganz viele Daten. Ich brauche eine gewisse Sicherheit, habe Checks in der Datenbank, klar, alles richtig, aber wie gesagt, wenn wir in die Realität blicken, wie viele Applikationen es in der Realität so gibt, kleine, die das sowieso nicht verwenden und wer kennt in SQL schon überhaupt die Check Class? In MySQL geht die sehr bedingt nur. Also wer verwendet die überhaupt z.B. um wirklich Daten zu checken.

Andy Grunwald (00:39:56 - 00:40:52)

Jetzt hattest du gesagt, deine Performance Tests, die du der Bild verkauft hast für die letzte Headline, dass Dateien schneller sind als Datenbanken, hast du mit PHP getestet? Und ich stelle mir gerade die Frage, PHP ist ja, ich nenne es mal eine stateless Sprache in einem normalen Web server Kontext. Es kommt ein Request rein, die PHP Engine schaut sich den PHP Code an, interpretiert, nicht kompiliert, interpretiert ihn und wenn das PHP Skript am Ende wieder fertig ist, dann wird wieder alles aus dem Memory gelöscht. Das bedeutet natürlich auch, dass bei jedem Aufruf der php Datei die Datei aufgemacht wird und zugemacht wird. Wohingegen natürlich bei einer ich nenne das mal stateful Sprache, bei einer kompilierten Sprache, bei einem laufenden Prozess, wenn der Prozess hochgefahren wird, dann kann natürlich die Datei geöffnet werden, eingelesen werden und einmal in den Arbeitsspeicher geladen werden. Was natürlich dann, so wie ich das jetzt gerade erzähle, wenn wir mal die Betriebssystem Caches außer Acht lassen, schneller sein sollte. Richtig?

Wolfi Gassler (00:40:52 - 00:41:08)

Ich würde sagen, dass es eher bei anderen Sprachen langsamer ist, weil die wirklich, wenn du, du musst ja irgendein JSON File verwenden oder ein XML File oder irgendwie ein Format und die Parser sind üblicherweise nicht so schnell.

Andy Grunwald (00:41:08 - 00:41:11)

Ich kann ja auch CSV verwenden, also Format ist ja wirklich egal.

Wolfi Gassler (00:41:11 - 00:42:00)

Ja, ist ja egal, was, was es für Format ist, aber du brauchst einen Parser und die Parser sind üblicherweise, würde ich mal sagen, langsamer als der klassische PHP Parser, der das im Hintergrund noch cached und wahrscheinlich halt schon nativ dieses Array, dieses multidimensionale Array in PHP aufnimmt, wenn du eine Datei öffnest und das im Hintergrund auch optimiert. Wenn du das selber programmierst und immer JSON Dateien einliest, JSON Dateien passt, bin ich mir nicht sicher, ob das mithalten kann mit PHP. Also ich vermute, durch diese include Funktion von PHP bist du wesentlich schneller. Ist jetzt aber auch nur eine Mutmaßung und kann ich nicht garantieren. Ich wollte schon lange mal das mit Jason nachprogrammieren, habe ich aber bisher einfach noch nie geschafft, dass ich das mal mache. Wer da contributen will, GitHub Repo ist public, kann man gerne mal reinschauen, verlinken wir natürlich.

Andy Grunwald (00:42:00 - 00:42:10)

Also jetzt habe ich das gerade erst richtig verstanden, wo du das erklärt hast. Also du sagst mir, also du hast eine PHP Datenstruktur, eine Variable in einer Datei geschrieben und die einfach nur mit include.

Wolfi Gassler (00:42:10 - 00:42:11)

Genau, genau.

Andy Grunwald (00:42:11 - 00:42:18)

Aber das solltest du doch eigentlich mit einem Jason, mit einer JSON Datei bei Node JS und und Dino und wie sie alle heißen, doch auch können, oder?

Wolfi Gassler (00:42:19 - 00:42:47)

Ja, wobei, also ich bin ja auf den Use Case gegangen, dass ich wirklich hunderttausende Dateien habe, also dass das gar nicht in den Hauptspeicher passt unter Umständen, sondern wirklich pro Objekt dann eine Datei ist und die dynamisch eingelesen wird, wenn ich sie brauche. Und da kann ich wahrscheinlich nicht mit require und so in Node JS dementsprechend arbeiten. Also das muss man dann schon immer einlesen und parsen und da bin ich mir nicht sicher, wie schnell der Parser ist. Wäre aber ein cooler Test, wenn man das mal implementieren würde.

Andy Grunwald (00:42:47 - 00:42:54)

Und ich glaube, du hast gerade nach etwas gefragt, was es schon gibt. Sagt dir die One Billion Road Challenge was?

Wolfi Gassler (00:42:54 - 00:42:56)

Nein. Aber du klärst mir gleich, die One.

Andy Grunwald (00:42:56 - 00:44:10)

Billion Road Challenge wurde original für Java ausgerufen, gibt es aber inzwischen für jede Sprache und auch auf Datenbankebene, auch auf Clickhouse und ähnliches. Und die beschreibt sich selbst, okay, wie schnell kann man 1 Billionen Rose, was glaube ich im Deutschen 1 Milliarde ist, aus einem Text File aggregieren, also in Java. Und da geht es natürlich rein um Performance und Optimierung des Codes und so weiter und so fort. Und die gibt es jetzt nicht nur für Java, die gibt es halt für ganz andere viele Sprachen. Und eigentlich ist doch das, was du gerade angefragt hast, oder? Also das haben schon ganz viele Leute gemacht, die vielleicht auch gesagt haben, Datenbank braucht man nicht, sondern eine Datei. Und vielleicht machen die auch Bit Shifting. Und deswegen möchte ich den Code eigentlich nicht sehen, weil der dann wieder viel zu kompliziert ist. Aber verlinken wir auch mal in den Show Notes, da gibt es unglaublich viele Experimente und da gibt es auch unglaublich viele Blogposts gerade, wie Leute sich zu Tode optimieren, 1001000000000 Rows aus einer Textfalt zu lesen. Aber jetzt frage ich mich gerade, jetzt sagst du, okay, gegebenenfalls ist PHP sogar schneller, weil das nativ in PHP weggeschrieben wird und dann durch die native include Thematik eingebunden wird. Aber auf der anderen Seite muss es ja jedes mal inkludiert werden, bei jedem Request, wohin du gegen bei einem GoProzess, bei einem Rust Prozess, bei einem Java Prozess oder bei einem Prozess ja die ganzen Sachen nur beim Startup einmal liest.

Wolfi Gassler (00:44:10 - 00:45:46)

Aber nur, wenn du es im speicher Platz hast. Also ich bin ja davon ausgegangen, dass du es nicht Platz hast. Und bei BAB kannst du es dynamisch inkludieren. Und das ist wieder schöne, das ist einfach, man nutzt die Werkzeuge, die da im Hintergrund schon jemand geschrieben hat und optimiert hat. Und ich bin mir sicher, da haben sich schon so viele Leute Gedanken gemacht, wie können wir im PHp File includes möglichst optimieren und irgendwie im Hintergrund cashen und abcashen und keine Ahnung was alles. Und dasselbe ist mit dem Betriebssystem, mit Dateien, da gibt es caches, da gibt es Optimierungen und darauf kann man aufbauen. Und das ist teilweise wirklich alles super, super optimiert und man glaubt gar nicht, wie schnell das eigentlich ist. Oder auch Netzwerkzugriff auf Shared Network Drives, wie optimiert dieser Zugriff sein kann. Also klar muss man immer ausprobieren und es kommt auf die Driver drauf an und das Protokoll und alles. Aber wenn man daran denkt, denkt man halt meistens an ganz was langsames und langsame Protokolle und Netzwerk und Filesystem ist auch langsam und alles ist langsam. Und in der Realität ist es aber oft gar nicht so. Und wenn man sich überlegt, was die Datenbank alles im Hintergrund macht, eben ACID garantieren, f Sync, die ganzen Handshakes, die da ablaufen, die Security, die Connections, die da aufgebaut werden, die Query Parser, die Optimizer, die da durchlaufen, die Query Execution Optimierungen, irgendwelche Mappings, die hin und her gemappt werden, dann wieder zurückschicken, du hast die Mappings zum C Client und und und. Also da sind so viele Schritte dazwischen, dass das halt oft einfach viel, viel langsamer dadurch ist, als wenn du einfach auf eine Datei zugreifst und das vergessen viele.

Andy Grunwald (00:45:46 - 00:46:29)

Hast du denn mal ein Tracing gemacht, weil du hast jetzt ganz viele Probleme oder beziehungsweise mögliche langsame Schritte erwähnt. Hast du mal ein Tracing gemacht und vielleicht gesehen, okay, die Authentication in meinem Connection Handshake, die frisst dreiig, %, weil dann kann man natürlich sagen, okay, die Authentication nehme ich ja raus, damit der Vergleich ja mal ein bisschen fair ist, weil in der Regel hast du ja bei einem Pfeilzugriff, ja hast du da Authentification durch die, durch die darf das Linux System da der User gerade darauf zugreifen, aber es ist ja nicht eine username Passwort Authentification. Also hast du da mal ein Tracing gemacht und wirklich gesagt, okay, das frisst dreiig, das 5 % und das ist vernachlässigbar, weil du sagst jetzt gerade Query Parsing, vielleicht ist das ja so hart optimiert.

Wolfi Gassler (00:46:29 - 00:47:11)

Natürlich ist es optimiert und klar, da haben sich auch viele Leute Gedanken gemacht und das ist wahrscheinlich so optimiert, wie es auch geht, aber es sind halt trotzdem viele Schritte, die gemacht werden und glaube ich habe die Connection auch gar nicht mitgerechnet, bin mir jetzt gerade nicht sicher, aber du hast natürlich einen Connection Pool, der aufrechterhalten wird und es geht halt um die Realität. Also ich habe das sogar durch HTTP durchgeschliffen, weil die wollten einen realen API Fall simulieren, wo das wirklich durch die API durchgeht hat HTTP, wo der Overhead auch von HTTP und so weiter immer dabei ist und trotzdem ist so ein großer Unterschied, obwohl da außen herum ganz viel Apache mit dabei ist und Connection Aufbau und HTTP und so weiter und trotzdem ist es so ein großer Unterschied zwischen den Varianten.

Andy Grunwald (00:47:11 - 00:47:16)

Mich würde hier wirklich mal einen Datenbank Tracing interessieren, also dass du ein Tracing.

Wolfi Gassler (00:47:16 - 00:47:22)

Komplett, kannst es gern dazu einbauen, der Code ist online, Andi, ich lade dich hier mit ein, du kannst es gerne.

Andy Grunwald (00:47:22 - 00:47:27)

Dementsprechend einbauen, vielleicht machen wir mal eine Challenge, vielleicht kriegen wir die Datenbank ja so hart optimiert, dass die schneller ist.

Wolfi Gassler (00:47:27 - 00:47:33)

Als dein FileZug, vielleicht findet auch irgendwer einen großen Fehler bei meinem Code.

Andy Grunwald (00:47:33 - 00:47:40)

Du musst ja verstehen, ich arbeite bei einem Datenbank as a Service Provider. Also wenn ich dir zustimmen würde, dann wäre das ja irgendwie nicht.

Wolfi Gassler (00:47:41 - 00:47:43)

Ihr könntet ja File as a Service anbieten in Zukunft.

Andy Grunwald (00:47:43 - 00:47:49)

Nennt man das nicht eigentlich Object Storage? Also S und Azure Blob und wie soll er heißen? Weil.

Wolfi Gassler (00:47:49 - 00:47:49)

Genau.

Andy Grunwald (00:47:49 - 00:48:09)

Ja, aber kommen wir mal zu deinem File as a Service. Da gibt es nämlich auch noch mal eine ganz interessante Geschichte. Du, wenn du von Files sprichst, sprichst du ja unter anderem ja auch von sqlite, richtig? Oder würdest du sagen, weil das ist ja eigentlich eine kleine File Datenbank, so eine Mischvariante. Würdest du sagen, das ist auch noch simpel genug?

Wolfi Gassler (00:48:09 - 00:48:33)

Ja, ich habe es zuerst kurz erwähnt. Also ich glaube schon, dass es auch noch eine Stufe unter einer klassischen Datenbank liegt. Aber du hast natürlich, je nachdem, wie du es betreibst, embedded hast du das Problem nicht. Dann kannst du es wirklich mit dem Code ausliefern. Aber sonst musst du natürlich trotzdem die die SQLite starten, schauen, dass sie läuft. Gut, Backups musst du dich eigentlich immer kümmern, aber.

Andy Grunwald (00:48:33 - 00:48:43)

Ja, aber starten, dass sie läuft, nee, musst du nicht. Es ist ein File Opener und dann Abfahrt. Ist ja kein Prozess, oder? Du kannst eine SQLite auf jeden Fall als Fall betreiben.

Wolfi Gassler (00:48:43 - 00:48:45)

Ja, stimmt natürlich. Ja.

Andy Grunwald (00:48:45 - 00:49:26)

Was es aber nebenbei gibt, ist auch ein Service, der nennt sich Lightstream. Und Lightstream, Achtung, streamt Changes von SQL Lite woanders hin. Also auf S oder auf Blob Storage oder auf Google Cloud oder auf SFTP oder NFS. Und jetzt fangen wir mal an zu sprechen, weil das ist natürlich schon irgendwie so eine Art streaming, so Kafka für die kleinen Menschen sozusagen. Kafka für die side Projects, weil ein Kafka zu betreiben oder ähnliches oder Revit MQ ist ja schon alles schon sehr, sehr teuer, weil muss man Infrastruktur haben und so weiter. Aber wenn ich da jetzt eine SQLite habe und die Changes werden wohin gestreamt, dann könnten natürlich Schreibzugriffe auch interessant werden, oder? In deinem simplifizierten Modell hier.

Wolfi Gassler (00:49:26 - 00:51:06)

Ja, klar. Also du kannst ja auch schreiben auf Dateien, die in dem Network Storage liegen in irgendeinem Form. Das geht ja genauso. Da könntest du dann sogar von verschiedenen Prozessen schreiben, je nachdem, dass natürlich das Problem gleichzeitig auf was geschrieben wird und so weiter. Also ist nicht super einfach. Ich glaube, der große Vorteil an sqlite oder einer Datenbank ist natürlich auch noch, wenn du Analysen fahren musst, wenn du die SQL Features wirklich verwendest, also wenn du das jetzt nicht als Blob Storage verwendest, wo du eben nur immer ein Objekt aufrufst oder vielleicht fünf Objekte aufrufst, wie es so klassisch bei einer Web Anwendung oft der Fall ist, wo man nur irgendwelche Einträge anzeigt, dann macht es natürlich Sinn, wenn man SQL zur Verfügung hat, um da irgendwelche Statistiken zu fahren, Aggregationen zu machen, Einschränkungen, Filter und so weiter, gar keine Frage. Aber in ganz vielen Applikationen brauchst du das nie und du verwendest da eigentlich das nur wie ein Key Value Store, würde ich fast sagen. Und und da ist natürlich dann die Frage, ob man nicht falsch macht. Aber wenn du es natürlich schaffst, es irgendwie zu streamen oder auszulagern oder über ein Fileshare zu machen, dann kannst du auch eigentlich ganz gut schreiben und für kleine Applikationen funktioniert es auch ganz gut. Und wenn du dann Cloudflare, z.B. die d Datenbank, wenn es mich nicht alles täuscht, d D, ich habe schon wieder vergessen, irgendeine Zahl verwendest, wo im Hintergrund auch SQLite läuft, dann hast du eine simple Datenbank auch in der Cloud zur Verfügung. Sowas funktioniert dann natürlich auch ganz gut und da ist die Wartung natürlich dann möglichst gering gehalten, weil du da nicht großartig dich um irgendwas kümmern musst. Und das ist dann schon fast wie ein Falls.

Andy Grunwald (00:51:06 - 00:51:28)

So langsam gehen mir die Streichhölzer aus, an denen ich so langsam ziehen muss, um die ganze Sache hart zu challengen. Weil ich habe mich gerade gefragt, okay, wie verhält sich die ganze Thematik denn im Cloud Native und Serverless Buzzword Bingo Umfeld? Aber wenn wir jetzt mal über Serverless sprechen und du sagst, du schippst eine statische Datei einfach mit deinem Code mit, dann ist das ja eigentlich total Perfekt für Serverless, oder?

Wolfi Gassler (00:51:28 - 00:52:22)

Genau, und skaliert natürlich out of the box. Du kannst es einfach 20 mal hochfahren, read only wohlgemerkt. Schreiben ist dann eine Schwierigkeit, aber ehrlich gesagt, das ist dann überall eine Schwierigkeit, weil wenn du mal so skalieren musst, dass du fünf Prozesse oder fünf Nodes brauchst, dann hast du wahrscheinlich auch das Problem, dass die eine Datenbank nicht mehr reicht. Dann musst du wahrscheinlich deine Datenbank verteilen und verteilte Datenbanken ist eine ganz andere Liga dann, eine ganz andere NR. Und klar, da sprechen wir dann von anderen Problemen. Also ist immer die Frage, wenn du, wenn du wirklich so viele Schreibzugriffe hast, dann brauchst du da eine andere Lösung und dann hast du allgemein Skalierungsprobleme. Also dann, dann macht es auch Sinn, skalierbare Datenbank zu verwenden, ist schon klar. Aber in ganz vielen Fällen ist es halt gerade wenn es so um Konfig Werte geht oder irgendwelche Werte, die sich einmal im Monat ändern, kannst du da so fünf Notes hochfahren und die schickst die Daten einfach immer mit, liegen in deinem Kit, alles kein Problem.

Andy Grunwald (00:52:23 - 00:52:28)

Und oft ist das natürlich schon Cloud native by design, wenn man dann von Immutability spricht und so.

Wolfi Gassler (00:52:30 - 00:52:50)

Und wenn du es natürlich, wenn du natürlich deinen Deployment Prozess auch so automatisiert hast, dass bei jedem Commit, das deployed wird, könntest du natürlich sogar irgendeinen Cronjob bauen, der, wenn es mal ein Update gibt von deinen Daten, direktes Update committed, dann wird deine gesamte Deployment Pipeline angeworfen, die Daten waren automatisch deployed, upgedatet und sind live.

Andy Grunwald (00:52:50 - 00:52:53)

Jetzt habe ich aber noch einen Punkt, der negativ ist.

Wolfi Gassler (00:52:53 - 00:52:55)

Und zwar, es gibt ganz viele negative.

Andy Grunwald (00:52:55 - 00:52:57)

Punkte, aber schiesslos, du redest die ganze.

Wolfi Gassler (00:52:57 - 00:53:04)

Zeit von Config Values als Platzhalter, aber Config Values sind Klassiker. Ja, den man auch gerne in der Datenbank speichert.

Andy Grunwald (00:53:04 - 00:53:22)

Genau. Und wenn die Config Value sich ändert, in der Regel queriet man die Datenbank dann neu. Also weil du sendest ja in der Regel ein Select Entry, select Query darüber und dann holst du dir das und so weiter. Wenn ich aber jetzt ein File in Memory lese, dann muss ich ja, ich sag mal, so eine Art Refresh Intervall bauen, der ja dann, ja, musst du.

Wolfi Gassler (00:53:22 - 00:53:33)

In der Datenbank auch, weil üblicherweise holst du die config Werte, wenn du startest, wenn du deine Applikation startest oder du hast ein Refresh drin, aber ob du ein Refresh von der Datenbank hast oder ein Refresh vom File, ist dasselbe.

Andy Grunwald (00:53:33 - 00:54:02)

Verflixt. Aber okay, ich meine, den Main Case haben wir ja schon gefunden. Und zwar, wenn es um mehrdimensionale geht. Datenbanken geht. Datenbanken, wenn es um mehrdimensionale Daten geht, Relationen und so weiter. Und da muss ich auch mal ganz ehrlich sagen, ich weiß nicht, ob ich die these mitgehe, dass sehr viele Leute, die den Datenbank nutzen, keine Datenbank brauchen. Denn es ist, denke ich, nicht so oft der Fall, dass du ein so simples Datenmodell hast, denn die heutige Welt ist viel zu komplex.

Wolfi Gassler (00:54:03 - 00:54:03)

Fair point.

Andy Grunwald (00:54:04 - 00:54:21)

Aber Wolfgang, das ist mir völlig egal. Hast du mir jetzt gerade ein schlechtes Gefühl gemacht. Und zwar hast du mir ein schlechtes Gefühl gemacht, dass ich anscheinend ein Junior bin, weil ich immer von Haus aus erstmal eine Datenbank dahin setze, weil Boring Software, ich soll ja das nutzen, was ich kenne, um einfach zu bewegen. Und jetzt hast du mir gerade das.

Wolfi Gassler (00:54:21 - 00:54:27)

Gefühl, naja, aber was gibt es noch langweiligeres als Files? Also richtig boring sind wohl Files.

Andy Grunwald (00:54:27 - 00:54:41)

Ja, aber es wird ja nicht anders gelehrt. Verstehst du? Meine komplette fachinformatiker Anwendungsentwicklung Ausbildung habe ich das gelernt. So danach in der Uni kam auch Datenbanken und allem drum und dran. Aber verstehst du, so niemand hat mich Files gelehrt.

Wolfi Gassler (00:54:41 - 00:55:22)

Ja, weil du lernst da ja auch nicht Startups und Tracking programmieren. Und zum starten ist halt trackig oft eine gute Variante. Keep it simple und es funktioniert. Und du bist nicht der einzige, weil bei dem Meetup war es ja auch so, dass das extrem viele Leute getriggert hat, auch danach in Diskussionen noch. Also ich kann es schon verstehen, das ist ein wirklich heißes Thema. Und darum war es mir wichtig, auch das mal in den Podcast zu bringen, weil es ist ein Streitthema und ich bin ja Datenbank Fan. Ich bin mein Leben lang irgendwie mit Datenbanken unterwegs gewesen. Und also gerade von meiner Seite, ich sehe natürlich die Vorteile von Datenbanken, aber du kaufst dir halt eine Komplexität ein, die vielleicht nicht überall nötig ist.

Andy Grunwald (00:55:23 - 00:55:38)

Was ich richtig schön finde, ist die Story am Anfang, auf die bin ich nicht eingegangen, wo du gesagt hast, in der Pause von diesem Meetup sind die Leute zu dir gekommen, was du davon hältst, anstatt mit dem Speaker selbst, der das Statement in den Raum gebracht hat, darüber zu diskutieren.

Wolfi Gassler (00:55:38 - 00:55:39)

Ja, es wurde schon mit dem auch.

Andy Grunwald (00:55:40 - 00:55:43)

Diskutiert, natürlich, aber ich kann dir einfach nicht zustimmen.

Wolfi Gassler (00:55:43 - 00:55:45)

Das ist nichts Neues für mich, weil.

Andy Grunwald (00:55:45 - 00:56:10)

Sonst redet mein Chef, glaube ich, mit mir. Du kannst doch nicht als Datenbank as a Service seit Reliability Engineer sagen, wir sollen alle Files nehmen. Aber zu den ganzen Leuten, die jetzt gerade an einem side Project arbeiten, lasst euch nicht vom Wolfgang unterbuttern. Ganz im Ernst, nutzt die Datenbank, über die ihr was lernen wollt. Weil ich denke nämlich zu 90 % macht man Zeit Projekt, um was zu lernen und nicht damit reich zu werden und sogenannt, wie du es geschrieben hast, dreckig Startup programmieren.

Wolfi Gassler (00:56:10 - 00:56:14)

Und ich freue mich natürlich auf ganz viele Konter in der Discord Community und.

Andy Grunwald (00:56:14 - 00:56:32)

Ich gehe stark davon aus, dass wir sehr, sehr viele Details vergessen haben. Aber ich meine, der Wolfgang hat ja auch schon ein paar Flows zugegeben, also Daten, Konsistenz und alles, was beim Schreibtisch Prozess untendrunter so schief gehen kann. Und diese, diese, diese Asset Thematik von Datenbanken. Also da sagt der Wolfgang ja auch da, da gibt es das Thema.

Wolfi Gassler (00:56:32 - 00:56:43)

Also einer Bank würde jetzt weniger empfehlen, ihre zentrale Infrastruktur auf Falls zu mappen oder auf Fallbasis zu stellen. Also da sind wir, glaube ich d'accord.

Andy Grunwald (00:56:43 - 00:56:44)

Wer? Du und die Bank.

Wolfi Gassler (00:56:44 - 00:56:46)

Du und ich, Andy.

Andy Grunwald (00:56:46 - 00:57:35)

Okay, obwohl der Woche mir ein schlechtes Gefühl gegeben hat, überlege ich jetzt gerade, habe ich einen neuen Hammer? Also suche ich mir jetzt gerade ein Problem, wo ich jetzt nur Files nutzen kann. Und deswegen würde mich mal interessieren, wie du dazu stehst. Hattest du schon mal ein side Project, was du als so simpel klassifizieren würdest, dass du retrospektiv sagst, ich hätte glaube ich lieber eine Datei nehmen sollen als eine Datenbank, dann wäre ich schneller gewesen, weil du dich jetzt z.B. nur mit dem Backup der Datenbank auseinandersetzt. Das würde mich mal interessieren. Komm doch mal in unsere Discord Community, findest du in den Show Notes oder auf Engineering Kiosk Dev, da gibt es so einen ganz großen Button, join Community oder join Discord und trag doch mal dein Use Case davor, dann da sind unglaublich fähige Leute, die auch sehr geile Ideen haben und mich immer wieder überraschen.

Wolfi Gassler (00:57:35 - 00:58:10)

Und vielleicht noch zum zum Abschluss, um dir zu zeigen, dass mich das innerlich auch zerreißt, dieses Problem. Ich möchte mein simples side Project jetzt erweitern mit Payment, dass man da auch eine Subscription abschließen kann. Und da bin ich jetzt gerade im inneren Konflikt. Soll ich das weiterhin in Jason schreiben, wenn jemand ein Payment durchführt und ich schreibe das nur in Jason? Oder brauche ich da eine ordentliche Datenbank? Zerreißt mich gerade intern, aber es geht halt nur um vielleicht überhaupt, wenn jemand bezahlt, bin ich mir gar nicht sicher. Also da bin ich noch am überlegen und unschlüssig, was ich machen soll.

Andy Grunwald (00:58:10 - 00:58:18)

Aber hat WhatsApp noch keine Zahlfunktion und solche Geschichten, die an der Account gebunden ist und die über die WhatsApp API läuft? Also würde mich wundern.

Wolfi Gassler (00:58:18 - 00:58:20)

Da gibt es gar nichts. Gibt's gar nicht.

Andy Grunwald (00:58:20 - 00:58:23)

Willst du nicht auf Telegram gehen oder auf Alipay oder so?

Wolfi Gassler (00:58:24 - 00:58:26)

Hat er die Maße nicht Alipay.

Andy Grunwald (00:58:27 - 00:59:05)

Das war es mal wieder von uns, von einer. Ich weiß nicht, was war das für eine Diskussion? Eine ganz komische. Also ich fühle mich total schlecht und ich bin noch nie so schlecht aus dem Podcast rausgegangen. Da muss ich jetzt erstmal eine Nacht drüber schlafen. Vielen Dank, dass du bis hierhin gehört hast. Gib dem Wolfgang mal kontra. Also hilf mir mir, Andi. Ich brauche Argumente gegen den Wolfgang. Was soll das denn hier? Das geht so nicht, dass der leider mich mal unter den Tisch redet. Nun gut, wir hören uns das nächste Mal. Und wenn du einen Datenbank Administrator hast bei dir in der Firma, vorworte doch mal bitte die Folge. Der wird wahrscheinlich ein paar Kontraargumente Gegenwart haben. Ich freue mich drauf. Wir hören uns bis zum nächsten Mal und tschüss.

Wolfi Gassler (00:59:06 - 00:59:07)

Ich freue mich natürlich auch und ciao.