Über 50 Jahre Queries: Das relationale Datenbankmodell und die Sprache SQL haben Geburtstag!
Relationale Datenbanken und die Abfragesprache SQL sind aus der modernen Welt nicht mehr wegzudenken. Egal ob du eine eigene Webseite mit WordPress betreibst, Business Intelligence Analysen für eine Versicherung machst oder die größte Oracle Datenbank der Welt betreibst - In allen Use Cases kommt das relationale Datenbankmodell und die Sprache SQL zum Einsatz.
Und SQL ist bei weitem kein neuer heißer Scheiß. SQL ist inzwischen 50 Jahre alt und das relationale Datenbankmodell ist sogar noch 5 Jahre älter als SQL! Welche Technologie fällt dir ein, die inzwischen so alt ist, aber dennoch eine solch aktive und breite Nutzung vorweisen kann?
Klar, COBOL, Fortan und Co sind bestimmt noch in irgendwelchen Kellern aktiv - Aber auch in diesem Volumen wie SQL?
Dieser Umstand hat uns dazu bewegt, einmal die Frage zu beleuchten: Wie kam es eigentlich zu relationalen Datenbanken? Wie wurde SQL eigentlich erfunden? Darum geht's in dieser Episode. Wir erzählen die Geschichte von SQL.
Inkl. Streit, welches Datenbankmodell das bessere ist, Wettbewerbe um die schönsten Queries zu schreiben, Behörden die Test-Suites für die Industrie schreiben und warum du IBM und Oracle ggf. mehr zu verdanken hast, als dir eigentlich lieb ist.
Bonus: SQL wurde mal totgesagt, doch totgesagte leben länger.
Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Das schnelle Feedback zur Episode:
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
- Bluesky: https://bsky.app/profile/engineeringkiosk.bsky.social
- Twitter: https://twitter.com/EngKiosk
Links
- 50 Years of Queries: https://cacm.acm.org/research/50-years-of-queries/
- Edgar F. Codd: A Relational Model of Data for Large Shared Data Banks https://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf
- Codd's 12 rules: https://en.wikipedia.org/wiki/Codd's_12_rules
- Engineering Kiosk Episode #99 Modernes SQL ist mehr als SELECT * FROM - mit Markus Winand: https://engineeringkiosk.dev/podcast/episode/99-modernes-sql-ist-mehr-als-select-from-mit-markus-winand/
- Edgar F. Codd: https://de.wikipedia.org/wiki/Edgar_F._Codd
- Michael Stonebraker: https://de.wikipedia.org/wiki/Michael_Stonebraker
- Charles Bachman: https://de.wikipedia.org/wiki/Charles_Bachman
Sprungmarken
Hosts
- Wolfgang Gassler (https://gassler.dev)
- Andy Grunwald (https://andygrunwald.com/)
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
- Bluesky: https://bsky.app/profile/engineeringkiosk.bsky.social
- Twitter: https://twitter.com/EngKiosk
Transkript
Andy Grunwald (00:00:00 - 00:00:08) 
So Andy, bevor wir heute in die Episode einsteigen, ich hätte noch eine kurze Ratefrage für dich. Und zwar kennst du ja Stackoverflow oder bist du schon komplett auf ChatGPT?
Wolfi Gassler (00:00:08 - 00:00:11)
Ne, ich glaube, Stackoverflow hatte ich heute schon noch ein paar mal auf.
Andy Grunwald (00:00:11 - 00:00:24)
Genau, die machen ja so eine Survey und da gibt es ja die 2024 Survey mit den beliebtesten Sprachen, auch Markup Languages. Jetzt, wenn man da mit alle einberechnet, was ist auf Platz eins?
Wolfi Gassler (00:00:24 - 00:00:31)
Ich weiß jetzt gerade nicht, wie die erhoben werden, ob das, ob das jetzt Google Suchergebnisse sind oder Repositories auf GitHub oder wie, oder Anzahl der Fragen zu.
Andy Grunwald (00:00:31 - 00:00:34)
Der Sprache auf Secoverflow oder Survey.
Wolfi Gassler (00:00:34 - 00:00:42)
Also Umfrage, OK, Platz eins, JavaScript oder Python, korrekt, JavaScript Platz zwei wahrscheinlich dann Python.
Andy Grunwald (00:00:43 - 00:00:48)
Fast ist Platz drei, weil es sind ja auch Markup Languages, also ist Platz zwei HTML. Genau.
Wolfi Gassler (00:00:48 - 00:00:53)
Ach du meine Güte. Und Platz vier, da tippe ich mal auf Java fast SQL.
Andy Grunwald (00:00:53 - 00:01:01)
Und wenn man auf professional developers eingrenzt, also man kann da filtern, learning to code, professional developers, dann ist auf Platz eins welche Sprache?
Wolfi Gassler (00:01:01 - 00:01:03)
Dann würde ich sagen SQL.
Andy Grunwald (00:01:03 - 00:01:13)
Immer noch JavaScript, aber du hast vollkommen recht, auf Platz zwei ist SQL. Also Andi, SQL kannst du ja, du musst jetzt eindeutig noch JavaScript lernen, um die zwei Top Sprachen zu erlernen.
Wolfi Gassler (00:01:13 - 00:01:30)
Aber da die meisten Javascriptler ja im Frontend unterwegs sind mit Vue, JS und React und so weiter, haben die ja in der Regel mit Datenbanken gar nichts zu tun. Das bedeutet, die schreiben ja da gar keine Datenbank queries, oder? Und wenn die doch serverseitiges JavaScript schreiben, dann nutzen die doch meist schon OEM, oder? Und dann machen die auch nur getObject von schieß mich tot und nicht select from, oder?
Andy Grunwald (00:01:30 - 00:01:33)
Ja, das hast du allgemein. Typescript ist übrigens auf Platz fünfte.
Wolfi Gassler (00:01:33 - 00:01:51)
Meines Erachtens nach sollte Typescript, weil Typescript wird ja in der Regel nach JavaScript transpiliert, weil es gibt ja keine native Typescript Engine, wenn du so möchtest, soviel ich weiß. Eigentlich sollte TypeScript so eine subsprache von JavaScript sein und deswegen in diesen Statistiken auch so ausgeführt werden, so nach dem Motto, du hast, weiß ich nicht, Platz.
Andy Grunwald (00:01:51 - 00:01:55)
Eins, dann wäre JavaScript noch weiter vorne. Das ist ja schon Platz erste.
Wolfi Gassler (00:01:55 - 00:02:01)
Ja gut, aber es gibt ja auch ganz viele Sprachen, obwohl, dann müsste man eigentlich auch alle Sprachen, die auf der JVM laufen, irgendwie zusammenfassen, oder?
Andy Grunwald (00:02:01 - 00:02:05)
Obwohl, stimmt, ja, Java ist übrigens auf Platz siebte.
Wolfi Gassler (00:02:06 - 00:02:28)
Naja, aber das geht auch zu weit. Aber du kennst das ja glaube keiner Statistik, die du nicht selbst gefakt hast. Deswegen habe ich gestern eine andere Statistik gelesen zur Vorbereitung zu dieser Episode. Und zwar war da die welche Sprache solltest du lernen, um die besten Job Opportunities zu haben auf Basis eines Crawling Ergebnis von Recruiting Seiten.
Andy Grunwald (00:02:29 - 00:02:30)
Ich würde sagen prompt.
Wolfi Gassler (00:02:30 - 00:02:33)
Und jetzt kommen wir mal von deiner AI Welt mal weg. Was steht da auf Platz eins?
Andy Grunwald (00:02:34 - 00:02:43)
Also wenn es nach Anzahl der Vorkommnisse einfach geht, dann könnte SQL auch weit oben stehen, weil SQL eigentlich fast in jedem Job Profile in irgendeiner Form erwähnt wird.
Wolfi Gassler (00:02:43 - 00:02:51)
Du hast recht und deswegen habe ich auch direkt gesagt, wie die ganze Sache erhoben wurde. Und zwar solltest du SQL lernen, um die besten Job Opportunities zu haben.
Andy Grunwald (00:02:51 - 00:03:12)
In der Tat, es gibt eigentlich keinen Job, wo man nicht irgendwo mit SQL in Kontakt kommt als Programmiererin, würde ich mal so sagen, ganz allgemein. Also irgendwo musst du die Daten immer abspeichern und da bietet sich halt SQL an. Und alle Data Scientists haben natürlich auch SQL, also alle Administratoren haben SQL. Also deckst du da im Prinzip das gesamte Feld ab. Macht absolut Sinn.
Wolfi Gassler (00:03:12 - 00:03:23)
Aber das, was wir gerade gemacht haben, ist auch so ein bisschen Confirmation Bias. Also wir haben uns jetzt ungefähr die Episode gerade so zurechtgelegt, haben uns Statistiken rausgesucht, die die Relevanz dieser Episode irgendwie belegen.
Andy Grunwald (00:03:23 - 00:03:29)
Ja, eigentlich müssten wir JavaScript machen, aber nachdem du JavaScript so hast, bleibt uns nur noch SQL übrig.
Wolfi Gassler (00:03:29 - 00:03:37)
Also ich hasse nicht JavaScript. JavaScript hat mir ja nichts getan. Es ist nur so, wenn ich in meiner Freizeit selbst entscheiden kann, was ich programmiere, ist es halt nicht JavaScript.
Andy Grunwald (00:04:37 - 00:04:48)
Wobei man da jetzt dazu sagen muss, also bevor jetzt alle irgendwie abschalten, wir machen jetzt keine Erklärung von SQL oder wie man eine SQL Query schreibt oder solche Dinge. Also es geht um ein anderes Thema.
Wolfi Gassler (00:04:48 - 00:06:00)
Und zwar haben wir im Podcast mehr oder weniger zwei Formate neben den klassischen Podcast Episoden aus dem Boden gestampft. Einmal waren das Podcast Episoden über Turing Award Gewinner, wo wir unter anderem schon mal über Alan Turing, Tim Berners Lee oder Barbara Liskop gesprochen haben. Und vor kurzem haben wir ein zweites Format aus dem Boden gestampft, das nannte sich Papers we love. Da ist die Grundidee, dass wir wissenschaftliche Paper nehmen, die durchlesen, erklären und dann einordnen oder vielleicht auch kritisieren. Diese Episode ist nichts von beidem. Diese Episode ist so eine Art Mashup kombiniert mit einer kleinen Geschichte, so à la es war einmal. Wir erzählen kein Märchen, sondern wir feiern eigentlich zwei, wie ihr an der Intro schon ein bisschen herausgehört habt, große und relevante Geburtstage, denn die Abfragesprache SQL wurde gerade 50 Jahre alt und das Konzept der relationalen Datenbanken wurde gerade 55 Jahre alt. Happy birthday to you. Happy birthday to you. Happy birthday. Und da der Wolfgang einen Doktortitel in der ganzen Datenbankthematik hat und sogar älter ist. Und sogar der ältere von uns beiden von uns ist.
Andy Grunwald (00:06:00 - 00:06:04)
Jetzt hast du dich noch rausgerettet, du sagst es älter ist als die Sprache oder so.
Wolfi Gassler (00:06:04 - 00:06:24)
Ne, du bist älter als ich. Und deswegen würde ich dich bitten, uns doch mal die Geschichte von SQL und relationalen Datenbanken zu erzählen. 50 Jahre SQL queries, 55 Jahre das Konzept der relationalen Datenbank. Wie sind wir hier gekommen und was waren die Ups and Downs, vor allem.
Andy Grunwald (00:06:24 - 00:06:47)
Zu Platz eins bzw. Platz zwei, je nachdem, welche Statistiken man nimmt. Also es ist immer noch relevant, weil du kannst jetzt sagen, ach, Cobol ist alt geworden oder sowas, aber SQL ist immer noch da. Wurde ja auch mal zwischenzeitlich totgeglaubt, aber es ist immer noch da. Und das ist eigentlich für mich dieses außerordentliche bei dieser Technologiesprache, also Programmiersprache ist es ja nicht so ganz.
Wolfi Gassler (00:06:47 - 00:06:56)
Also wenn ihr wissen wollt, wie er Systeme und Abfragesprachen erschafft, die auch noch 50 Jahre danach auf Platz eins bleiben, dranbleiben.
Andy Grunwald (00:06:56 - 00:07:04)
Also im Prinzip müssen wir da ja jetzt wirklich weit, weit zurückspringen. Also eigentlich zur Mondlandung, die ja wann stattgefunden hat, Andi?
Wolfi Gassler (00:07:04 - 00:07:07)
Verschwörungstheoretiker würden. Hat die überhaupt stattgefunden?
Andy Grunwald (00:07:08 - 00:07:11)
Perfekt, ich hab nämlich auch keine Ahnung. Ist aber auch gar nicht so relevant.
Wolfi Gassler (00:07:11 - 00:07:14)
1969 habe ich gerade mal nachgeguckt.
Andy Grunwald (00:07:14 - 00:08:34)
69. Perfekt. Weil die Datenbank, die da auch verwendet worden ist, das war noch ein hierarchisches Datenbanksystem, ist 1967 von IBM erschaffen worden, das war die IMS. Und das waren eigentlich so die ersten Datenbank Netzwerk Datenbanksysteme und hierarchische Datenbanksysteme, die die Daten von dem Code getrennt haben. Also musst du dir so vorstellen, früher hat man, ich kenne das leider auch nur aus Geschichten, also so alt bin ich jetzt auch wieder noch nicht, aber früher hat man so Lochkarten geschrieben oder später dann auf Bänder, diese Magnetbänder, das kennt heutzutage auch schon wieder niemand, wenn man jetzt das mit Kassette vergleicht, aber diese oldschool Magnetbänder, die da so bei den alten James Bond Filmen im Hintergrund laufen oder so, vielleicht kennt man es daher noch, da war eigentlich der Code oben, den man geschrieben hat und die Daten zwischendrin. Also im Prinzip hat man da eigentlich ganz viele Variablen im Code, mehr oder weniger Datenblöcke gehabt und mit denen hat man gearbeitet. Also da gab es keine Trennung. Und die hierarchischen Datenbanksysteme oder Netzwerk Datenbanksysteme, die waren in den Mitte er Jahren, die haben zum ersten mal da eine Trennung vollzogen. Das war ursprünglich dann teilweise noch auf Band, aber so richtig cool ist es dann eigentlich geworden, wie zum ersten Mal diese Spinning Discs auf den Markt gekommen sind. Jetzt ist die muss man das heutzutage auch schon erklären, wo alles SSD ist und nur mehr SSD Festplatten verwendet werden?
Wolfi Gassler (00:08:34 - 00:08:57)
Ich glaube, da können wir schon voraussetzen, dass die meisten unserer Hörerinnen und Hörer Spinning Disc klassische HDDs, Hard Disk Drives noch kennen. Wenn nicht, einmal ganz kurz googeln, da seht ihr mal, wie groß die Dinger noch waren. Und wenn man ganz genau zuhört, hier in meinem Büro läuft gerade noch ein NAS mit zwei Spinning Discs und zugegeben, das ist ein bisschen laut, deswegen, ich hoffe, der Wolfgang schneidet das später raus.
Andy Grunwald (00:08:57 - 00:10:15)
Stimmt, ich brauche noch einen Nass mit Spinning Discs. Aber das coole an Spinning Discs war das erste Mal, dass man springen konnte, weil da war dieser bewegliche Arm und die Platte hat sich gedreht und man konnte mit diesem Arm springen. Das war ja bei den Bändern nicht möglich. Bei den Bändern musstest du ja wirklich von ganz hinten nach vorne immer hin und her spulen, damit du irgendwas finden konntest. Also springen war kaum möglich. Und mit diesen Netzwerk Datenbanken drum Netzwerk, weil man da einfach beliebige Knoten miteinander verbinden konnte, weil man ja von Knoten zu Knoten springen konnte, von Datenpunkt zu Datenpunkt, war das eigentlich die große Revolution damals über diese wirklich Hardware Technologie. Erst dann war es möglich, da sinnvoll das zu trennen und das erste Mal einen Code zu haben, der unabhängig von den Daten operiert. Und dann, je nachdem, was für ein Datum gebraucht wird, holt man sich das rein in den Speicher, verarbeitet das, kann es wieder rausschreiben. Also das war so der Beginn eigentlich der klassischen Datenbanksysteme. Da gab es aber noch kein SQL. Und was vielleicht auch für die Bingo Karte ganz wichtig ist, IBM kennt man ja so als Datenbank Firma, aber die erste Netzwerk Datenbank des IDS System von 1964, das war von General Electric damals erstellt, weil wie gesagt, die haben halt auch Hardware dementsprechend erstellt. Also sollte man unbedingt wissen, nicht nur IBM war zu dieser Zeit im Business.
Wolfi Gassler (00:10:15 - 00:10:25)
Ich habe gerade mal nachgeguckt, was General Electric eigentlich heutzutage so macht. Auf Wikipedia wird als Mischkonzern beschrieben. Da muss ich erst mal gucken, was ist ein Mischkonzern?
Andy Grunwald (00:10:25 - 00:10:29)
Die machen alles mit Turbinen und so Elektrik und so Zeug, oder?
Wolfi Gassler (00:10:29 - 00:11:02)
Die machen eine ganze Menge im Energiebereich, erneuerbare Energien, aber auch Öl und Gas, die sind anscheinend in der Aviation Industrie, also in der Luftindustrie unterwegs, Transportsysteme, die haben auch ein paar Kapitalgesellschaften, die sich um Geldanlagen für Privatkunden kümmern, die sich um Immobilien kümmern, um Leasing und Flottenverwaltung. Also wenn das nicht die Definition von Mischkonzern ist. Ich wusste nicht, was ein Mischkonzern ist, aber gut, ich dachte, jemand, der ein Tausendsassa, wird man vielleicht sagen. Und das ist es, glaube ich.
Andy Grunwald (00:11:02 - 00:11:18)
Aber es ist interessant, dass eben die nicht mehr im IT Business sind. Hingegen z.b. die hierarchische Datenbank IMS von 1967 von IBM, die eben für die Mondlandung auch verwendet wurde, die gibt es immer noch, die kannst du installieren. Da gibt es eine neue Version, Version 11, glaube ich, ist die aktuelle.
Wolfi Gassler (00:11:18 - 00:11:20)
Aber ich bin mir nicht sicher, ob du die jetzt installieren kannst.
Andy Grunwald (00:11:20 - 00:11:25)
Ja, das ist eine andere Geschichte. Wahrscheinlich braucht man auch einen Mainframe dafür, würde ich jetzt mal schwer wetten.
Wolfi Gassler (00:11:25 - 00:11:32)
Ganz genau, die ist nämlich für das ZOS verfügbar. Und das ZOS ist meines Wissens nach das Betriebssystem für Mainframes.
Andy Grunwald (00:11:32 - 00:11:34)
Aber was für eine Version ist die aktuelle?
Wolfi Gassler (00:11:34 - 00:11:35)
15.
Andy Grunwald (00:11:35 - 00:11:38)
Da war mit meinem 11 knapp daneben.
Wolfi Gassler (00:11:38 - 00:11:50)
Genau. Hardware Voraussetzungen sind IBM System Z Prozessoren und softwareseitig brauchst du eine Java Runtime, eine cobra Runtime, eine DB, eine IBM Websphere. Klingt mir nach einem Schiff.
Andy Grunwald (00:11:50 - 00:12:20)
Wichtig dabei ist aber, diese Datenbanken, das waren alles noch keine relationale Datenbanken, wie wir sie heute kennen. Und dafür müssen wir mal jetzt lockere 10 Jahre drauf springen. Also wir springen ins Jahr 1974, jetzt erst mitte er in die ER. Und 1974 ist das erste Mal das IBM System, System R, also R implementiert worden oder gestartet worden als Research Projekt. Das war die erste Datenbank, die wirklich das relationale Modell implementiert hat.
Wolfi Gassler (00:12:20 - 00:12:33)
Aber wie kann ich mir das vorstellen? Bei IBM Saß, ein unglaublich intelligenter Mensch und hat so, ich habe gerade gut gefrühstückt, Müsli mit Joghurt, zwei Kaffee habe ich auch schon drin, man gebe mir eine Tastatur, ich baue mal was.
Andy Grunwald (00:12:33 - 00:13:13)
Ja, mehr oder weniger, muss man sagen. Aber grundsätzlich basierte das Ganze natürlich auf einem Paper, was schon früher existierte. Kennt man vielleicht alle, die mal auf der Uni waren und Datenbanken gehabt haben, die haben wahrscheinlich das relationale Modell gelernt, also ganz abstrakt. Und auch die relationale Algebra. Also das war so die mathematisch, oder ist immer noch die mathematische Form, die eigentlich hinter SQL steht. Und die ist zum ersten Mal 1970 von, heißt der Edgar? Weiß ich schon den Vornamen nicht mal, aber von Cott, von Edgar, hat sicher noch einen Mittelbuchstaben. Andi Frank, Edgar, Frank Kott heißt das.
Wolfi Gassler (00:13:13 - 00:13:20)
So, Edgar Frank in Anführungszeichen von jedem Te, genannt Cott, danke Andi, das siehst.
Andy Grunwald (00:13:20 - 00:14:04)
Du, jetzt habe ich so viel mit Kot, mein ganzes Unileben habe ich mit Kot beschäftigt, aber den vollen Namen bekomme ich nicht her. Aber Dieser Cott hat wirklich viel geschaffen, weil der hat 1970 eben dieses Paper, a relational model of data for large shared data banks herausgebracht und das war wirklich die mathematische Foundation, die heute noch nach 50 Jahren überall noch verwendet wird. Also das ist wirklich das relationale Modell, wie man es kennt, mit Tabellen, mit Joins, mit Relationen und auch das mathematische Regelwerk im Hintergrund, also wie funktioniert ein Join, wie funktioniert ein kartesisches Produkt, wobei Joins, bin mir gar nicht sicher, ob Joins im Paper schon drin waren, aber die ganzen Projektionen, die Selektionen und das war eigentlich alles schon in dem Paper drin, aber es war rein mathematisch, da hat es kein System gegeben zu dem Ganzen.
Wolfi Gassler (00:14:04 - 00:14:35)
Leider lebt der Kollege nicht mehr, 2003 ist er verstorben, als Background war er britischer Mathematiker und das war natürlich der Grund, warum das Paper größtenteils auf Mathematik oder auf, ich sag mal, reiner Theorie besteht. Und für das Paper, bzw. Für das Paper und alles, was danach kam, bitte bleibt dran, wenn ihr die Geschichte weiterhören wollt, hat dieser Mensch auch einen Turing Award bekommen 1981, da habt ihr auch die Relation, warum das hier so Papers we love und Turing Award Gewinner ist ein Mashup.
Andy Grunwald (00:14:35 - 00:15:20)
Was ja auch interessant war, dass dieses Paper ja ziemlich Wellen geschlagen hat, also es haben ja alle irgendwie cool gefunden, dieses Paper, aber es hat dann wirklich noch gebraucht, bis die ersten Implementierungen so langsam gekommen sind. Und da hat es parallel auch verschiedene Implementierungen gegeben, also da hat es nicht nur den COD gegeben und System r, sondern da ist auch der gute alte Michael Stonebreaker dann mit ins Spiel gekommen. Und die waren natürlich auch nicht alleine, also da hat es immer mehrere Leute im Team gegeben, das waren Forschungsgruppen, also da gibt es schon viele, die da mitgewirkt haben, aber die zwei großen Köpfe, COD, Stonebreaker, die waren sicher ganz stark in dem ganzen Game drinnen. Stonebreaker hat Ingress gegründet in den ERN auf der Berkeley University und COD war.
Wolfi Gassler (00:15:20 - 00:15:26)
Im IBM Research Programm oder eins von, ich glaube, 20 IBM Research Programmen.
Andy Grunwald (00:15:26 - 00:16:17)
Und was auch super interessantes Fakt ist, dass man zu der Zeit eigentlich dieses Paper zwar cool gefunden hat, aber es hat eigentlich niemand geglaubt oder ganz viele waren das sehr skeptisch, ob man das überhaupt machen kann, ob man es schafft, eine allgemeingültige Abfragesprache zu bauen mit dieser relationalen Algebra, die dann dynamisch irgendwie auf den Daten operiert, also was heutzutage absoluter Standard ist, haben damals diese Spezialisten wirklich bezweifelt, dass das möglich ist, weil man muss ja irgendwie diese Abfragesprache übersetzen in den Maschinencode, der dann abläuft. Wie kann das optimiert überhaupt über die Bühne gehen? Und was auch sehr cool ist, wenn man dann liest, sie haben sich eigentlich alle gedacht, Menschen können das sicher viel besser. Also es kann der Computer doch nicht so intelligent sein, dass der ein Mapping von der Sprache auf einen Ausführungsplan macht und das so intelligent wie ein Mensch. Das kann eigentlich nicht funktionieren.
Wolfi Gassler (00:16:17 - 00:16:42)
Also ich meine, wir reden hier von 1970 bis 1974, da ging es halt wirklich darum, Register zu laden. Wer vielleicht schon mal ein bisschen so assembly geschrieben hat, weiß, wovon ich da so spreche. Oder wirklich Arithmetik auszuführen. Also wie übersetzt man das? Eigentlich war die konnte man zu der Zeit einen Query Optimizer und einen Query Executor und eine Query Engine bauen? Das war eigentlich die Frage, oder Wolfgang?
Andy Grunwald (00:16:42 - 00:17:17)
Man würde das heute so nennen, damals war das natürlich was anderes, aber das ist heute genau der Query Optimizer, der natürlich hoch optimiert die SQL Anweisungen dann übersetzt in den Ausführungsplan und der Ausführungsplan dann natürlich hochoptimiert auch ausgeführt werden kann. Das war ja damals auch so. Wie kannst du ohne, also du hast es ja kompilieren müssen. Früher war kompilieren ein ganz aufwendiger Prozess. Wie kann man das dynamisch machen? Also das waren eigentlich die die großen Schwierigkeiten. Und wir sind immer noch nicht bei SQL. Also wir hatten da schon Datenbanksysteme, relationale Datenbanksysteme, aber wir hatten noch kein SQL.
Wolfi Gassler (00:17:17 - 00:19:08)
Bevor wir zu SQL kommen, gab es noch ein recht amüsantes Event, zumindest aus der heutigen Perspektive. Und zwar gab es wichtiges auch, ja, vielleicht auch ein wichtiges, obwohl ja doch eigentlich schon sehr wichtiges, denn 1974 hat eine Konferenz stattgefunden und zwar die SIG Fidet, die Special Interest Group on File Definition and Translation. Da gab es bestimmt ganz viele Workshops und so weiter und so fort, aber da gab es drei Sessions, die für diesen Talk hier relevant sind. Und zwar hat der Wolfgang ja initial auch von Bachmann geredet und von dem System von IDS von General Electric. Ihr erinnert euch, man kann auf einer Hard Disk hin und her springen und Daten lesen. Das ermöglicht natürlich, dass man dann auch diese Datenbanksysteme baut. Bachmann, General Electric hat dann ein Datenbanksystem gebaut, IDS, was so ein bisschen anders funktioniert hat als dieses relationale Modell, was Cott gemacht hat. Auf dieser Konferenz hat Bachmann sein Konzept vorgestellt, hat Cott sein Konzept vorgestellt und danach gab es so eine Art Panel. Also da sitzen dann zwei Leute, jemand interviewt und die beantworten Fragen. Und es war zwar als Panel beworben, aber jeder wusste wirklich, okay, es war wirklich eine Debatte. Und es ist genau das, was ihr jetzt gerade denkt, Debatte. Also ich lese da, die haben sich mal schön auf der Bühne gefetzt, wer eigentlich das bessere Modell hat. Und das zaubert mir gerade so ein bisschen, irgendwie ein bisschen amüsantes Kopfkino in meine Gedanken. Naja, auf jeden Fall war danach, nach dieser Sikfied Konferenz, in dem ganzen Research Bereich relativ klar, okay, das relationale Datenmodell, das, was die Leute vorher mit dem mathematischen Paper vielleicht nicht so ganz gut verstanden haben, weil es halt so mathematisch matisch war, war nach dieser Debatt auf jeden Fall, ich sag mal, gut verstanden. Jeder wusste, okay, wir haben hier zwei Modelle, aber irgendwie können wir die noch nicht abfragen.
Andy Grunwald (00:19:08 - 00:19:52)
Was vielleicht da auch wichtig sich vorzustellen ist, da gab es kein Internet. Das heißt, du hast nicht einfach mal googeln können, was gibt es denn zu System r? Das gab es alles noch nicht. Also da musstest du auf eine Konferenz fahren, damit du den Input bekommst. Also du hast ja nicht gewusst, was machen die anderen Forschungsgruppen. Klar hat es Veröffentlichungen gegeben, aber die waren ja auch sehr langsam. Also das war wirklich ein Zentrum eigentlich für Inspiration und auch einfach für Meinungsbildung, weil das hat es einfach gebraucht. Du hast sonst keine Möglichkeit gehabt. Und das wird uns später auch noch begleiten. Also man muss das auch unter dem Gesichtspunkt sehen, dass wir da in einer ganz anderen Welt und Zeit leben und dass es da natürlich viel schwieriger war, auch Sachen zu entwickeln und zu erfinden.
Wolfi Gassler (00:19:52 - 00:20:24)
Wie soll es anders sein? Was heutzutage wahr ist, war auch 1974 wahr. Wenn man auf einer Konferenz ist, sich da Sachen angesehen hat, was passiert dann? Man kommt hyped zurück, voll motiviert und will hacken. Und eigentlich haben das Chamberlain und Boyce auch gemacht nach der Konferenz, nach den beiden Konzepten, die vorgestellt wurden, nach der Debatte waren die beiden so hyped und haben sich hingesetzt und haben Sequel gebaut. SQL steht für Structured English Query language.
Andy Grunwald (00:20:24 - 00:21:19)
Also nicht das SQL, wie wir es heute kennen, sondern wirklich S e Q u E L. Also das war wirklich die originale Herkunft dieser Sprache. Und genau darum wird die auch so ausgesprochen. Darum sagen ganz viele, vor allem im amerikanischen Raum, zu SQL, SQL. Das ist rein, weil früher die Sprache Sequel hieß, hat sich das irgendwie erhalten in der Sprache, vor allem in Amerika. Und interessanterweise ist es immer noch in vielen Köpfen drin. Ich habe es gerade kürzlich in einem anderen Podcast gehört, die gemeint haben, eigentlich müsste das Sequel ausgesprochen werden SQL und sie sprechen es immer SQL aus. Stimmt so nicht. Also die ursprüngliche Sprache Sequel, aber man kann natürlich zur neuen SQL ganz normal SQL sagen. Also das ist nur in manchen Köpfen noch drinnen. Obwohl die alle noch nicht in den ERN gelebt haben, ist es trotzdem ein historischer Brocken, der noch immer bei uns in den Köpfen ist.
Wolfi Gassler (00:21:19 - 00:22:14)
Man muss dazu sagen, Chamberlain und Boys, die die SQL gegründet haben, waren auch beide bei IBM und waren beide inzwischen auch Teil des System A Research Projekts. Also die haben da auch mehr oder weniger mit COD zusammengearbeitet und haben dann mit SQL die erste Abfragesprache für die relationale Datenbank System A geschrieben. Und als sie sich hingesetzt haben, um die Schwangerschaft der Sprache zu designen, haben sie sich eine Keyfrage gestellt und zwar wer benutzt das Ganze? Wer ist eigentlich die Zielgruppe? Und da sind die zu dem Entschluss Data Scientists? Ne, leider nicht. Also die Keyfrage war, welche Zielgruppe benutzt das eigentlich? Für wen designen wir das denn eigentlich? Und damals war die Annahme, dass das keine Programmierer nutzen, sondern dass das der Versicherungsanalysten nutzt oder einfach jeder, der Daten abfragen möchte. Und deswegen wurde sich so nah an die englische Sprache angelehnt, um das wirklich simpel zu designen zu können.
Andy Grunwald (00:22:14 - 00:22:17)
Also das Beißen der Anfragesprache quasi.
Wolfi Gassler (00:22:17 - 00:22:27)
Ja, also ich mein Select Datum, Titel from orders, wenn das und das zutrifft, ist ja schon englisch, muss man ja sagen.
Andy Grunwald (00:22:27 - 00:23:01)
Was ich sehr geil gefunden habe, ist die Geschichte, wie sie die Sprache entwickelt haben, weil die haben sogenanntes Query Game gespielt, haben sie es zumindest genannt. Die haben probiert, echte Probleme in einer fiktiven Anfragesprache umzusetzen und haben sich dann gegenseitig gebettelt. Wer schafft es, eine fiktive Anfragesprache zu entwickeln, die schöner ist, die einfacher zu verstehen ist, einfacher zu lesen ist. Und so haben sie sich hin und her gebettelt, bis dann am Ende Sequel herausgekommen ist und die in ihren Augen die schönste Sprache war und die, die am einfachsten zu verstehen.
Wolfi Gassler (00:23:01 - 00:23:47)
Das mit dem einfach zu verstehen haben sie Walk up and read Eigenschaft genannt. Also du sollst einfach hinkommen und die Query lesen können. Das, was wir gerade gesagt haben, ist nämlich mehr oder weniger Version eins von SQL, weil in Version eins von SQL gab es eigentlich nur Select Statements, da ging es wirklich nur um Datenabfragen. Es gab noch mal so eine zweite Version 1976, zwei Jahre später nannte sich SQL zwei. Da kam dann auch so was wie Insert, Delete und Update dazu und auch View Definitions und Trigger Actions, also eigentlich ziemlich viele Hauptfeatures, die man heute von der aktuellen Abfragesprache so kennt. Und dann wiederum ein Jahr später, 1977, wurde SQL dann abgekürzt bzw. Gekürzt in wirklich SQL, also SQL, was dann wiederum für Structured Query language steht, so wie wir es heute kennen.
Andy Grunwald (00:23:48 - 00:24:01)
Und der Grund für das Ganze, für die Abkürzung ist natürlich auch wieder ein genialer Grund, das war einfach schon ein eingetragener Markenname, das heißt, SQL war einfach nicht mehr frei und sie hatten dann rechtliche Probleme und haben das einfach auf SQL umbenannt.
Wolfi Gassler (00:24:01 - 00:24:17)
Das war ein eingetragener Wagenname. Das stimmt. Von einer Flugzeug Company. Leider konnte ich nicht herausfinden, oder es ist unklar, für welches Flugzeug, denn die Firma Hawker Sideley Aircraft Company hat nie ein Flugzeug mit dem Namen Sequel oder so rausgebracht. Gerne hätte ich das mal.
Andy Grunwald (00:24:17 - 00:24:20)
Es kann ja auch ein Produkt sein, muss ja gar kein Flugzeug Name sein.
Wolfi Gassler (00:24:20 - 00:25:01)
Zu der Zeit wurden aber auch, und das muss ich diesen Leuten hoch anrechnen und auch IBM hoch anrechnen, über das, wo wir jetzt so relativ schnell drüber gesprungen sind, so die ganze Forschung zu SQL und SQL und System A und dann von dem System von Stonebreaker mit Ingress, weil ich meine, die hatten ja beide irgendwie so dieselben Herausforderungen, System A von IBM, Ingress von der Berkeley, die hatten so beide die okay, die mussten irgendwie die Datenbank da bauen, da mussten die user Interface bauen mit einer relationalen Abfragesprache, mit einem optimizer Compiler, um effiziente Ausführungspläne zu bauen. Und in dieser Zeit haben sie auch ziemlich viele Forschung veröffentlicht, was jetzt vielleicht.
Andy Grunwald (00:25:01 - 00:26:10)
Für Stormbreaker jetzt noch weniger untypisch ist, weil Stormbreaker war ein Universitätsprofessor an der Berkeley, aber für IBM, die hatten ja kommerzielle Produkte, für die war das eigentlich nicht so klassisch. Und da war IBM eigentlich schon jeher sehr stark, dass die in der Wissenschaft ziemlich tief verankert waren und auch heute noch IBM eine Firma ist, die sehr viel wissenschaftliche Papers veröffentlicht. Und für damalige Verhältnisse war das natürlich auch was ganz Neues. Und die haben sich wirklich gegenseitig befruchtet, COD und Stonebreaker, bzw. Alle, die da dranhängen natürlich an den zwei Gruppen. Und das war wirklich wahrscheinlich ein Grund, warum dann die Datenbankwelt auch dementsprechend schnell vorangekommen ist. Und das schadet wirklich nichts, wir können das gerne verlinken, mal in diese originalen Papers reinzuschauen, die sind gar nicht so schwer zu verstehen und sind wirklich gut aufgebaut. Also es war eigentlich schon wirklich auch dafür gedacht, dass man wirklich die Informationen teilt und voneinander lernt. Und das macht eigentlich schon die Wissenschaft aus. Also das war schon Vorzeigeprojekt, würde ich mal so das Ganze nennen. Und sie haben auch gemeinsam dann COD und Stonebreaker 1988 den ACM Software System Award für diese ganze Arbeit bekommen, die sie da geleistet haben.
Wolfi Gassler (00:26:10 - 00:28:37)
Über viele, viele Jahre, also wo sich die Berkeley Universität und IBM gegenseitig befruchtet haben, kam aber noch mal einer von der Seitenlinie, der hat sich die ganze Sache einfach mal angesehen und zu seinem eigenen Profit umgebaut. Und zwar kommt jetzt eine sehr schöne Story, wie man einfach offene Forschung nimmt, so nach dem Motto, und ihn als Elfmeter einfach mal verwandelt. Und zwar diese ganze Thematik mit 1977, mit der Abfragesprache SQL und so weiter und so fort, wurde natürlich auch in Paper veröffentlicht. So, und damals gab es eine Firma, die nennt sich SDL, Software Development Laboratories. Die Gründer der Firma haben sich die ganze Sache so angesehen von der Seite, was machen die denn da und so weiter, sofort noch festgestellt, ja Moment mal, IBM baut ja diese relationale Datenbank mit der Abfragesprache System A, aber die bauen das primär für die Mainframes. Wie sieht das denn eigentlich mal für andere Computerplattformen aus? Was hat SDL die Firma gemacht? Die haben auch eine relationale Datenbank gebaut in C, damit die auf günstigere Hardware als im IBM Mainframe laufen kann und dass sie besser portierbar ist. Wenn du heutzutage nachdenkst, man schreibt das in C, damit es besser portierbar ist. 1977 war das bestimmt alles andere als einfacher, aber nun gut, man rede hier heutzutage nur über libc und Massel C, aber egal, das ist ein anderes Thema. Auf jeden Fall haben die diese relationale Datenbank gebaut, haben sich die SQL Sprache genommen, haben die ebenfalls gebaut und haben diese Software dann verkauft. Also eigentlich hat Software Development Laboratories die erste kommerzielle Implementierung von SQL gebaut. So, und jetzt kommt's, die sind dann natürlich sofort auch an den Markt gegangen, 1978, 1909 und siebzigste. Zu diesem Zeitpunkt könnte man sich ja Moment mal, warum hat denn IBM eigentlich keine relationale Datenbank mit SQL Release? Ja, folgendermaßen, weil System für IBM ja ein Research Projekt war und IBM ja schon eine Datenbank draußen hatte, ihr EMS System, wollten die ihre Sales auf Basis EMS Systems nicht kannibalisieren, deswegen haben sie noch keine relationale Datenbank genommen. Warum erzähle ich die ganze Story? Wer ist denn eigentlich SDL? SDL hat sich 1979 in Oracle umbenannt. Oracle hat sich die ganze Thematik geschnappt, hat eine DB gebaut, hat die auf den Markt geschmissen und hat bis 1983 erstmal den kompletten Datenbankmarkt für sich abgegrast, bis 1983 dann IBM mit ihrer Datenbank DB um die Ecke kam. Bis dahin hatte Oracle leider, leider schon den datenbanken Markt erobert.
Andy Grunwald (00:28:37 - 00:28:46)
Da sieht man wieder, wie tief das in der DNA von Oracle schon verwurzelt war. Bevor sie Oracle geheißen haben, haben sie da einfach was übernommen und ordentlich vermarktet.
Wolfi Gassler (00:28:46 - 00:28:52)
Auf der einen Seite smarter Move, auf der anderen Seite klingt es auch wie so eine Story, wie der Bösewicht aus irgendeinem Marvel comic.
Andy Grunwald (00:28:52 - 00:29:25)
Jetzt war zu dieser Zeit SQL einerseits von IBM natürlich, aber auch von Oracle, nennen wir es jetzt mal Oracle, am Markt. Es gab aber auch noch Ingress, eben die Stormbreaker Variante, und die hatten Quell als Sprache. Also die waren sehr ähnlich, haben auf das relationale Modell natürlich aufgebaut von COD, aber es war noch nicht so ganz klar, wer da gewinnt. Die haben so 1978 da angefangen mit der Battle und haben sich dann probiert natürlich am Markt durchzusetzen. Und da gab es noch keinen Standard, der sich einfach durchgesetzt hat zu dieser Zeit.
Wolfi Gassler (00:29:25 - 00:29:45)
Apropos Standards, heutzutage kennt man das ja, die ANSI, die American National Standards Institute, das Komitee, was eigentlich sagt, okay, was jetzt hier ein Standard ist, man sagt ja auch ANSI C oder ANSI SQL. 1978 wurde nämlich dieses Komitee erst mal gegründet. Die haben sich dann, und zwar wichtig.
Andy Grunwald (00:29:45 - 00:29:48)
Nicht in Deutschland, obwohl es ein Standardisierungskomitee.
Wolfi Gassler (00:29:48 - 00:30:24)
Ist, wir könnten jetzt natürlich wieder diesen Running Gag mit DIN Norm ausrufen, aber lassen wir mal lieber. Und die haben sich 1978 gegründet, mit der Grundidee, einen Markt zu schaffen, auf dem Datenbankanbieter miteinander konkurrieren, eine Standardschnittstelle zu implementieren, auf dem die Benutzer die Gewissheit haben, dass es für mehrere Quellen für kompatible Produkte gibt. Finde ich erstmal ganz cool, was das, was man heute mit OpenTelemetry hat, dass man dann von Datadog zu New Relic wechseln kann und so weiter und einfach nur den Endpoint umdrehen muss, gefühlt. Also eigentlich wollten die den Vendor Login vermeiden. Und wie Wolfgang damals schon sagte, 1982.
Andy Grunwald (00:30:24 - 00:30:26)
Gab es eigentlich zwei, wie Wolfgang damals.
Wolfi Gassler (00:30:26 - 00:31:05)
Schon sagte, und wie Wolfgang gerade schon sagte, gab es damals zwei Query Sprachen, einmal SQL und einmal QL. Und dann war die große, okay, aber mit welcher Sprache beschäftigen wir uns denn jetzt? Weil wir hätten jetzt einen Würfel werfen können. Aber irgendwie haben sie entschieden, und zwar haben die folgendermaßen gemacht, sie haben beschlossen, die zukünftige Arbeit auf SQL weiterzuführen, weil die IBM Vertreter eine detaillierte Sprachspezifikation vorlichten konnten. Ich weiß jetzt nicht, warum der Stonebreaker das nicht konnte. Das stand da leider nicht. Das konnte ich auf Basis der Research nicht finden. Vielleicht haben sie auch einfach mal gecodet, wie Wissenschaftler programmieren, wissen wir ja alle.
Andy Grunwald (00:31:05 - 00:31:07)
Wolfgang Ich sage nichts dazu.
Wolfi Gassler (00:31:08 - 00:31:15)
Auf jeden Fall hatte IBM eine Spezifikation und dann hat sich der Ausschuss gedacht, ach komm, wenn eine Spezifikation schon da ist, dann war super.
Andy Grunwald (00:31:16 - 00:32:10)
Es war natürlich auch die Verbreitung einfach die ganz andere, weil IBM und Oracle hatte zu der Zeit natürlich auch eine ganz andere Marktmacht. Das war natürlich ganz was anderes als jetzt wieder so ein kleines System bzw. Sogar ein Forschungsprototyp, würde ich fast sagen. Also das macht natürlich schon Sinn. Es war auch interessant, dass die sich überlegt haben, sollen wir jetzt einen neuen, perfekten Standard schreiben, der alles beinhaltet, was so nötig ist für das Ganze, oder sollen wir einfach nehmen, was schon am Markt ist und schon implementiert ist? Und sie haben sich dann für letzteres entschieden, was dann schon eigentlich ganz schlau war, anstatt wieder mit irgend so einem neuen Standard um die Ecke zu kommen und dann hoffen, dass die Datenbankanbieter den implementieren, weil das ist immer so das Problem in Standard. Und das war mehr so der, würde mal sagen, der Cisco Approach, wie man heutzutage nennt, dass man einfach das, was schon am Markt ist, einfach zum Standard macht. Und damit ist der Standard schon implementiert bei den wichtigsten Playern im Markt.
Wolfi Gassler (00:32:10 - 00:32:53)
1986 haben sie die ganze Sache dann offiziell gemacht mit dem ersten offiziellen SQL Standard, SQL 86 heißt der. Und seitdem gibt es eigentlich regelmäßig neue SQL Standards, man sagt so circa alle fünf Jahre. Der letzte Standard kam 2023 raus und hat den ganz komischen Namen SQL 23, SQL 86, wer hätte es gedacht? Wer ein bisschen mehr zu den SQL Standards selbst wissen möchte, der soll mal in unsere Episode 99 reinhören. Die kam im November 23 raus mit Markus Wienand. Er verdient mit SQL eigentlich dein Geld und kennt sich da in den verschiedenen Standards und auch in den verschiedenen Dialekten sehr, sehr gut aus.
Andy Grunwald (00:32:53 - 00:33:20)
Was da auch interessant ist, was wir eigentlich heutzutage als SQL ansehen, also das ganz klassische deklarative Select stern from table und so weiter, das war in dem ursprünglichen Standard schon drin. Also die ganzen Erweiterungen haben dann Sachen dazu gebaut, die wir jetzt wahrscheinlich so im Alltag gar nicht nutzen. Also was wir heutzutage nutzen, diesen SQL Standard, der ist wirklich aus den ER Jahren eigentlich und der deckt den Großteil ab, was man so mit relationalen Datenbanken einfach so macht.
Wolfi Gassler (00:33:20 - 00:34:42)
1986 kam der erste SQL Standard raus. 1992, sechs Jahre später, hat sich NIST mal gedacht, das National Institute of Standards and technology, das ist die Organisation, die eigentlich die ganzen Spezifikationen schreibt und die ganzen Anforderungen schreibt, damit z.B. relationale Datenbanken von den US Regierungen erworben und genutzt werden können. Und zwar wurden diese ganzen Anforderungen in einem Standardpapier namens FIPS 127 festgehalten. Kann man vielleicht mal googeln, das ist jetzt nicht so sonderlich spannend. Ich glaube, das macht das BSI hier auch in Deutschland so weit, so gut. Da gibt es also ein Institut, die schreiben Spezifikationen für die Behörden, alles klasse. Aber was damals spannend war, FIPS 127 hat auch eine Testsuite enthalten mit mehreren 100 Testfällen. Und somit haben die ein Service angeboten, wo Datenbankhersteller ihre Datenbank Engine, ihr Query Parser und allem drum und dran gegen diese Testsuite schmeißen konnten und sagen kann, kann ich meine Datenbank jetzt an die Behörden verkaufen. Diese Testsuite war ungefähr identisch mit dem SQL 1992 Standard. Und das war natürlich mega gut. Jetzt hatte man endlich mal eine standardisierte Testsuite, die von verschiedenen Datenbankherstellern genutzt werden konnte. Das hat natürlich dann die Konkurrenz befruchtet.
Andy Grunwald (00:34:42 - 00:35:29)
Und ab da ist es dann eigentlich Schlag auf Schlag gegangen. Also das sind so die er er, wo dann wirklich die Datenbanksysteme um den Markt gekämpft haben. Also wir haben ja DB und Oracle schon erwähnt als die zwei wirklich großen Player. Und da hat IBM natürlich dann auch einfaches Spiel gehabt, mit alle Banken und so weiter da umzusteigen, auch vom IMS System. Gab dann aber auch ein paar neue Anbieter, Cyber Informix, Ingress, auch als kommerzielle Variante. 89 ist dann der Microsoft SQL Server relativ spät dazugekommen und bis dahin war eigentlich alles noch so im kommerziellen Umfeld. Also da konnte man noch viel Kohle mit Datenbanken verdienen. Auch heute, wer sich auskennt beim Oracle Lizenzmodell, puh, da muss man schon eine große Geldtasche haben, dass man sich eine Oracle Lizenz leisten kann.
Wolfi Gassler (00:35:29 - 00:35:32)
Lizenzieren die eigentlich immer noch nach CPU Cores?
Andy Grunwald (00:35:32 - 00:36:44)
Es gibt verschiedene Lizenzmodelle, die haben mittlerweile auch so eine kostenlose Variante, eine kleine, aber du rennst sehr schnell eigentlich in die kommerziellen rein und das sind ganz ordentliche Preise, die da immer noch aufgerufen werden. Und das war eigentlich so der Zeitpunkt, wo zum ersten Mal so in Richtung Open Source sich was gedreht hat. Und da ist natürlich MySQL als der große Name zu nennen, 1995 auf den Markt gekommen und damit hat sich dieses ganze Datenbankumfeld auch verändert und die haben natürlich alle SQL verwendet. Also da war dann SQL eigentlich schon gesetzt. Später ist dann Postgres noch dazugekommen, 1997 aus dem ursprünglichen Ingress von Stormbreaker heraus entstanden. Und ab diesem Zeitpunkt war es eigentlich möglich, dass sich normalsterbliche eben auch Datenbanken leisten. Da ist dann die ganze Internetwelle noch dazugekommen in den Mitte ern und man hat mit einem LAMP server Linux, Apache, MySQL ganz klassisch einfach so eine Webseite betreiben können, Web App bauen können und ich glaube, der Rest ist dann eh Geschichte von den Datenbanken bis heute, wo Postgres jetzt wieder MySQL bisschen den Rang abläuft und jetzt heutzutage eigentlich kaum mehr irgendeine Datenbank auf den Markt kommt, die nicht open source ist.
Wolfi Gassler (00:36:44 - 00:37:22)
Ja und wie wir alle wissen, MySQL wurd 2008 von Sun Microsystems gekauft, 2010 hat dann Oracle Sun Microsystems gekauft und dann hat der Gründer von MySQL, Monty 2010 MySQL geforkt und daraus ist MariaDB entstanden. Also eigentlich, wenn man die ganze Historie jetzt mal so ansieht, Oracle sollte doch eigentlich ganz eine ganz gute Heimat für Datenbanken sein. Natürlich, klar, habe ich ja vorhin gesagt, der böse Kollege, der von der Seitenlinie einfach mal sich auf die auf die freie Forschung stürzt und alles kommerzialisiert, okay, aber hey, Datenbankfirma ist eine Datenbank Firma.
Andy Grunwald (00:37:22 - 00:37:33)
Und MySQL ist ein super Produkt immer noch geworden, würde ich mal sagen, oder ist immer noch, wie man sieht. MariaDB darf man natürlich auch nicht vergessen zu erwähnen, muss man ganz klar sagen, ist mittlerweile auch ein großer Player geworden.
Wolfi Gassler (00:37:33 - 00:38:16)
Ja, obwohl natürlich in der MySQL Community gerade sehr, sehr viel, ich sag mal ein bisschen, wird ein bisschen hitziger. Also die ganze MySQL Community ist not amused über das MySQL 84 Release, weil die Innovation fehlt. Denn sie werfen Oracle vor, alles in ihr proprietäres MySQL Cloud Produkt zu schießen, die ganze Innovation. Und das sieht man auch, das MySQL Cloud Produkt von Oracle kriegt tolle neue Features. Die Community Edition lässt man so ein bisschen, ich sag mal am langen Arm vielleicht noch nicht verhungern, aber die Innovation ist schon sehr enttäuschend, was da in dem neuen Release Cycle ist. Besonders als sie jetzt aufgerufen haben, wir machen jetzt Innovation Releases. Innovation hat da leider ein bisschen gefehlt, deswegen warten wir mal ab, wie das so weitergeht.
Andy Grunwald (00:38:16 - 00:38:30)
Umso besser für Mariadb. SQLite habe ich übrigens natürlich auch noch vergessen zu erwähnen, hat natürlich in den er Jahren auch noch einiges verändert. Also Datenbanken überall bis zum Handy, weil SQLite ja wirklich jetzt auf jedem Handy wahrscheinlich läuft.
Wolfi Gassler (00:38:30 - 00:39:51)
SQLite ist nach eigenen Angaben sogar das am weitesten verbreitete Datenbanksystem der Welt. Also es läuft ja auf jedem iOS Device, auf jedem Android Device, in jedem Browser läuft es, auf jedem Betriebssystem ist es irgendwo eingebettet. Und was das tolle an SQL Light damals war, so wie heute auch, obwohl heute gibt es dann vielleicht noch ein paar Competitor ist, dass es im Vergleich zu MySQL oder Postgres oder Ingress oder Microsoft SQL Server oder Oracle und sowas halt kein Client Server Modell ist, sondern wirklich direkt eingebettet wird als Library und kann dann genutzt werden. Das war das tolle damals an SQLite. Aber die Story von Postgre, die finde ich auch so ein bisschen schön. Der Wolfgang hat das gerade so ein bisschen angerissen. Und zwar Ingress selbst war ja ein Research Projekt der Berkeley University. Das Research Projekt war irgendwann mal zu Ende. Auf Basis des Research Projektes gab es ein zweites Research Projekt, das nannte sich Postgres. Das ging auch irgendwann zu Ende. Dann hat sich eine Gruppe von Freiwilligen gefunden, die sich PostgreSQL global Development Group nannte. Und daraus ist dann das heutige PostgresQL entstanden. Das finde ich doch eine schöne Story. Also eigentlich kann man zwei Forschungsprojekte und eine Gruppe Freiwilliger. Und jetzt wird es auch von einer Gruppe Freiwilligen maintained. Also daher kommt Postgre. Vielen lieben Dank an die Uni von Berkeley, würde ich mal sagen.
Andy Grunwald (00:39:51 - 00:40:13)
Stoprak hat ja dann auch noch ganz viele andere Datenbanksysteme entwickelt, die wirklich marktbewegend waren, würde ich mal sagen, und auch Ausgründungen erfahren haben. Also Seestore, HStore, CIDB, das sind also Konzepte und Prototypen, wo es dann auch kommerzielle Produkte gegeben hat. Also von Berkeley ist schon viel gekommen, muss man ihnen schon lassen. Ganz federführend natürlich unter Stormbreak.
Wolfi Gassler (00:40:13 - 00:40:37)
Ja, und nicht nur die BSD Lizenz, also die haben wir, glaube ich, noch gar nicht erwähnt. Postgres selbst gilt als die umfangreichste und komplexeste Open Source SQL Implementierung. Das mag vielleicht der Grund sein, warum ziemlich viele Oracle Datenbanken, die weg von Oracle gehen, dann in der Regel auf Postgre migrieren, denn da der SQL Standard schon sehr exzessiv unterstützt wird früher war.
Andy Grunwald (00:40:37 - 00:41:18)
Einfach Postgres nie so stabil, würde ich mal sagen, oder es war komplex einzusetzen. Und die haben dann aber einfach extrem aufgeholt in den letzten 10 Jahren. Und das ist natürlich jetzt einfach ein top Notch Produkt. Und warum es dann jetzt auch so viele verwenden wollen, weil das war ja eigentlich immer das Gute an MySQL damals in den ERN. Mysql konntest du als normalsterblicher aufsetzen. Für Oracle brauchtest du mal fünf Certificates und sechs Spezialistinnen, dass du da irgendwie irgendwas aufsetzen konntest. Und das haben eigentlich die Open Source Projekte dann dementsprechend auch gezeigt, wie es wirklich gehen kann. Und heutzutage gehen dann auch viele Datenbanken in die Richtung, dass es eben einfacher ist aufzusetzen, nicht mehr Optionen braucht, bis man da irgendwas beim Laufen hat.
Wolfi Gassler (00:41:18 - 00:41:52)
Ja, und da sind wir auch schon fast in der heutigen Zeit angekommen, denn 2010 gab es noch mal ein Event, da wurde eine neue Sau durchs Dorf getrieben, die mit dem Namen NoSQL NoSQL da war, kann ich mich nicht dran erinnern. Ganz lang die Frage was heißt das denn jetzt? Darf man da jetzt kein SQL drin haben? Ist eine Datenbank, die eine Query Language so ähnlich wie SQL hat, überhaupt NoSQL? Und da habe ich bei der Recherche auch eine schöne Analogie gefunden, denn ab und zu heißt NoSQL auch not only SQL.
Andy Grunwald (00:41:52 - 00:44:17)
Ja, es hat sich dann eigentlich später so durchgesetzt, dass man sagt, es heißt ja not only, weil es hat dann wieder Datenbanken gegeben, die SQL gesprochen haben, aber aus dem NoSQL Segment waren. Und das war dann etwas schwieriger. Ich kann mich noch gut erinnern, 2009 ist ja MongoDb so an den Start gegangen und ich war ja damals auch viel in der Webwelt unterwegs und da war so cool, diese Datenbank skaliert automatisch über mehrere Knoten und die macht jetzt wirklich Konkurrenz zu diesen oldschool Datenbanken, langsamen Datenbanken. Und ich war dann 2010 auf der VLDB, also das ist die größte Datenbankkonferenz, die war damals in Singapur und da gab es auch wieder so ein Panel und zwar von war der Stonebreaker mit an Bord, das waren glaube ich, so fünf Leute und die halt über die NoSQL Datenbanken gesprochen haben. Und das waren alles Datenbankprofessoren, alles Männer natürlich aus der alten Zeit. Und ich bin da so als Jung Spund hingekommen und habe mir gedacht, die reden jetzt wirklich über NoSQL und NoSQL wird alles bewegen und verändern. Und ich war auch selber ein großer NoSQL Fan eigentlich am Anfang. Und dann kam halt zu Stonebreak und hat gesagt ist alles Mull, ist alles Müll, das könnt ihr komplett vergessen. Wir haben vor 20 Jahren selber Datenbanken gehabt, die nichts gekonnt haben und keine Acid Properties unterstützt haben. Und jetzt fangt ihr an, da von unseren guten datenbanken Sachen wegzuschneiden, um sie wieder dümmer zu machen. Und die gute SQL Query, die sich so etabliert hat, fangt jetzt wieder an wegzustreichen. Ihr seid ja alle verrückt. Also es waren wirklich so quasi seine Worte damals. Und ich hab mir nur gedacht, das ist halt der ignorante Professor, der hat keine Ahnung eigentlich und es wird sicher einiges ändern. Und mittlerweile, wenn ich so rückblickend auf den ganzen Trend schaue, tja, er hatte wohl recht, würde ich mal sagen. Und seine Argumentation damals war auch, man braucht es gar nicht alles wegschmeißen, Ace z.B. man kann auch Datenbanken schnell machen, einfach machen und in verteilte Systeme packen, ohne auf AC z.B. zu verzichten. Es war die ganze New SQL Wave, die es danach gegeben hat und er hat ja gezeigt, dass es auch funktioniert. Und das HANA System z.B. von SAP ist der beste Beweis, dass das auch funktioniert. Also er hatte, vielleicht war er trotzdem ignorant damals, aber er hatte auf jeden Fall recht. Und ich würde mal sagen, mittlerweile ist NoSQL zumindest als Begriff kein großes Thema mehr. Und es geht wieder vielleicht zurück zu den klassischen Datenbanken. Und die bauen jetzt immer, immer mehr Features ein. Die können chasen, die können spaltenorientierte Zugriffsmuster, die können verteilt über mehrere Knoten laufen, Clustersysteme und, und, und.
Wolfi Gassler (00:44:17 - 00:46:35)
Ja, wenn man dir so zuhört, dann klingt das alles schon sehr negativ, als bräuchte man das gar nicht. Da würde ich bei weitem nicht mitgehen, denn ich denke, NoSQL hat schon eine Daseinsberechtigung, nämlich ganz stark in verschiedenen Use Cases. Denn klassische Transaktionen und Asset und allen sowas braucht man vielleicht nicht immer, besonders in dieser schnelllebigen, modernen Webwelt mit Millionen von Benutzern, wo ja NoSQL eigentlich auch herkommt 2010 bzw. Weswegen die ganzen Thematik natürlich hochkommt. Denn wenn wir uns jetzt mal ganz kurz und ganz brutal und ganz simplifiziert auch vor Augen führen, was ist eigentlich anders an no SQL, so im Groben und Ganzen zu relationalen Datenbanken, dann sind das eigentlich mehr oder weniger vier Punkte. Und zwar, dass NoSQL eigentlich ein loses, partielles oder vielleicht auch gegebenenfalls gar kein Schema hat. Denn relationale Datenbanken, so zumindest nach Cott, nach dem Erfinder von relationalen Datenbanken, der hat nämlich auch ein. Der hat nämlich auch kotz 12 Regeln aufgestellt. Und die wichtigste ist Regel Nr. Eins the information rule, all information in a relational database is represented explicitly at the logical level and in exactly one way by values in tables, wo die Tabellen. Gut, da spricht er jetzt nicht wirklich von Schema, aber das ist natürlich auch ein Hint auf das Schema. Und NoSQL Datenbanken haben gegebenenfalls ein loses, partielles oder auch gar kein Schema. Und da kommen wir auf die nächste Welche NoSQL Datenbanken haben denn eigentlich gar kein Schema? Z.B. nämlich Dokumentendatenbanken, OpenSearch oder du hast gerade von MongoDB gesprochen oder vielleicht sogar ganz simpel Key Value, Redis, Valkyrie, Dragonfly, das sind so die Vertreter oder die populären Vertreter. Memcached vielleicht auch, oder memcache, die für Key value dann machen die natürlich auf Basis der Geschwindigkeit auch Kompromisse in Themen wie Transaktion und Asset, hatten wir gerade schon mal gesprochen, Stichwort eventual consistent, besonders wenn man irgendwie mehrere Nodes hat. Und natürlich gegebenenfalls haben NoSQL Datenbanken auch ein simpleres user Interface. Das bedeutet, sie implementieren vielleicht nicht die ganze SQL Sprache, vielleicht auch irgendwie eine eigene Sprache. Redis hat ja eher ein Get Set Modell anstatt wirklich eine Abfragesprache. Also ich weiß nicht, ob ich dir da zustimmen würde und Stonebreaker auch nicht.
Andy Grunwald (00:46:35 - 00:47:33)
Also du hast natürlich vollkommen recht, diese Trends, die existieren, meiner Meinung nach ist einfach dieses Wort NoSQL nicht mehr so gehypt und wird auch gar nicht mehr gerne verwendet. Also ich kenne jetzt spontan auch keine Datenbank, die NoSQL sich jetzt irgendwie auf die Werbepage oder so schreibt. Aber die Konzepte natürlich, die sind aber jetzt eher auch in die normalen klassischen Datenbanken reingewachsen, weil dokumentenorientierter Store, z.B. du hast in Postgres MySQL, JSON Datentypen, wo du einfach JSON rein dumpen kannst, aber trotzdem auch suchen kannst, Indizes drüberlegen kannst. Also das sind dann Features in den klassischen Datenbanken geworden. Und es gibt natürlich sehr spezialisierte Datenbanken, Graph oder wirklich ein Key Value Store, einen klassischen, die man früher alle unter NoSQL irgendwie reingestopft hat, auch die Graph Datenbanken. Ich habe das nie ganz verstanden, warum man die dort reingenommen hat, aber hat sich wahrscheinlich gerade angeboten. Und mittlerweile versuchen sich Datenbanken über andere Bereiche abzugrenzen und über die Features und weniger über irgendein Schlagwort wie Noise.
Wolfi Gassler (00:47:33 - 00:48:49)
Also ich stimme dir zu, dass das heutzutage nicht mehr so beworben wird, nicht mehr so relevant ist, aber hier ist meine these, als die ganze Thematik 2010, 2009, 2011 hochkam und man erstmal in die ganzen Firmen irgendwie rein musste, brauchte man eine einfache Klassifizierung. Das ist ganz ähnlich wie heute mit AI. Wenn man heutzutage von AI redet, redet man eigentlich von generative AI und alles andere an künstlicher Intelligenz wird erstmal zur Seite geschoben und man simplifiziert das einfach, weil das einfach ist, das versteht jeder. Heutzutage sind wir erwachsener, denke ich. Heutzutage sagen wir, das sind Graf Datenbanken, das sind Dokumentendatenbanken, das sind Key Value Datenbanken und so weiter und so fort. Und heutzutage kennen wir auch viel besser die Use Cases und deswegen wird das Mutterwort, die Generalisierung NoSQL, vielleicht gar nicht mehr so genommen. Denn du hast auch, heute sagt man auch direkt Postgres oder Oracle und man sagt nicht, ja, wir nutzen eine relationale Datenbank. Relationale Datenbank ist die Familie und darunter sind die Produkte und hier hat man vielleicht irgendwie ganz oben NoSQL und dann hat man die einzelnen Familien wie Document Store und so weiter und darunter dann die Produkte. Deswegen, ich denke, wir sind alle einfach erwachsener geworden und das jetzt auch der CTO weiß, okay, wenn ich jetzt Elastic oder OpenSearch nehme, dann habe ich eine Dokument Datenbank oder mongodb oder ähnliches. Deswegen denke, das entwickelt sich einfach so weiter.
Andy Grunwald (00:48:49 - 00:48:51)
Es kommt mir nur schwer über die Lippen, aber ich muss dir fast recht.
Wolfi Gassler (00:48:51 - 00:50:32)
Geben, Andi, das freut mich aber jetzt. Jetzt ist natürlich auch die große Frage, wir reden so positiv über SQL, wir reden so positiv über die Historie und was das alles bewegt hat und wo SQL heute ist. Aber es gibt auch Kritik an SQL, und zwar, dass die SQL Sprache, dass es der an Orthogonalität fehlt. Kompliziertes Wort, ich musste auch erst nachschlagen, was das im Detail heißt. Deswegen versuche ich jetzt mal zu erklären und der Wolfgang berichtigt mich jetzt. Die Operatoren einer orthogonalen Sprache retournieren die Werte ohne Seiteneffekte und man kann sie eigentlich fast immer miteinander kombinieren. Was heißt das jetzt? Wenn wir uns einfach mal z.b. die einzelnen Befehle von SQL anschauen, dann hat man select from table where statement group by schieß mich tot. So ein klassisches SQL Statement. Dann hat man aber ganz andere, unterschiedliche Syntax bei insert, updates und deletes. Bei insert hat man z.B. das values Keyword, bei Updates hat man z.b. das set Keyword und bei delete, gut, da hat man gar kein Keyword, delete from table where, irgendeine Einschränkung. So, und bei diesen drei Befehlen z.b. kann man jetzt kein Group by setzen. Das bedeutet, diese Syntax, oder auch nicht bei jedem SQL Statement kann man, glaube ich, ein Group by setzen, abhängig davon, was man macht. Du kannst halt nicht jeden Operator mit jedem Operator einfach so kombinieren. Und das ist die Stärke von einer Sprache, die orthogonale Operatoren hat. Das ist einer der Kritiken an SQL, weil man muss sich halt schon immer merken, okay, wann kann ich wo, in welchem Kontext jetzt welchen Operator nutzen? Ist das einigermaßen zutreffend, Herr Dr. Ja.
Andy Grunwald (00:50:32 - 00:51:51)
Würde ich auch so sehen. Ganz klassisch in der Mathematik hat man, wenn man jetzt ein Plus Symbol hat, das kann man halt überall einsetzen und miteinander kopieren, miteinander kombinieren oder mal Symbol und so weiter. Also das wäre das Gegenteil, was wirklich orthogonal ist, weil man es dementsprechend auch verwenden kann. Ist auch ganz interessant, im Artikel von Chamberlain, der ja zusammen mit Beuys die SQL Sprache entworfen hat, der sagt eben auch, dass Beuys damals einfach einen anderen User im Kopf hatte. Also der hatte nicht irgendwie einen Informatiker, Informatikerin im Kopf, die da kombinieren anfängt und da die Orthogonalität braucht, sondern die hatten halt einfach diesen klassischen, wirst du es genannt, Versicherungsfritzen. Versicherungsanalysten, genau, im Kopf und da war das einfach nicht so wichtig. Und da ist auch ein kleiner Unterschied zur relationalen Algebra. In der relationalen Algebra, die ja wirklich mathematisch ist, die funktioniert da wesentlich besser. Und group by gibt es in der relationalen Algebra, wenn ich das jetzt richtig im Kopf habe, gar nicht. Das sind also Konstrukte, die im Nachhinein dazu gebaut wurden in SQL. Und darum kann man auch nicht jede SQL Anfrage in relationale Algebra übersetzen oder umgekehrt, weil das eben schon verschiedene Modelle sind oder leicht unterschiedliche Modelle. Wir hatten das an der Uni immer probiert, so automatisch zu übersetzen für Studentenbeispiele, funktioniert leider nicht.
Wolfi Gassler (00:51:51 - 00:52:08)
Die Orthogonalität ist einfach daran geschuldet, dass die ganze SQL Sprache eigentlich an die englische Sprache angelehnt wurde. Wie wir schon damals gesagt hatten, das Walk up and read Konzept. Du sollst eigentlich fast jede SQL Query durch englische Sprache mehr oder weniger lesen können.
Andy Grunwald (00:52:08 - 00:52:46)
Ein anderer Punkt, der oft genannt wird, sind, dass die Sprache bzw. Eigentlich die Resultate von einer SQL Abfrage auch Duplikate beinhalten kann, obwohl wir ja von Relationen sprechen. Und auch da wieder der Unterschied zur relationalen Algebra, wo es hier um Relationen geht. Und in einer Relation dürfen eigentlich Rows nicht doppelt vorkommen, kann aber sehr wohl in einem Result Set sein. Also auch da wieder so eine mathematische Ungenauigkeit, die jetzt vielleicht so beim normalen Anwenden gar nicht so schlimm ist, aber sobald du natürlich irgendwie in die Mathematik reingehst oder darauf Sachen aufbaust, können solche Sachen dann schon gewisser Weise ein Problem darstellen. Natürlich, sobald du auf die mathematische Ebene gehst.
Wolfi Gassler (00:52:54 - 00:53:35)
Und als dritte Kontroverse wird immer genannt, dass auch Query Ergebnisse bzw. Werte in Tabellen null Values beinhalten können. Und das muss ich zugeben, habe ich nicht ganz verstanden, warum das jetzt eine Kontroverse oder warum das ein Nachteil ist. Denn im Endeffekt ist es ja so, dass du zwar mit dem Wert null sagen kannst, dieser Datenwert existiert noch nicht, im Gegensatz zu dem Wert null, also der Zahl null. Und dass nur weil du ein Record hast, also eine Row mit fünf Feldern, kann es ja sein, dass ein Datensatz, also ein Feld, erst zu einem späteren Zeitpunkt kommt und dann dieser Wert null sein kann. Also deswegen habe ich die Kontroverse nicht verstanden. Kannst du mir das erklären?
Andy Grunwald (00:53:35 - 00:53:46)
Hattest du nie, wenn du, du hast ja auch mal studiert damals in Datenbanken, hattest du nie das Problem, wenn du Felder geprüft hast, ob die null sind und z.B. ist gleich null geschrieben hast?
Wolfi Gassler (00:53:46 - 00:53:49)
Ich habe das heute noch. Ich muss immer den Operator nachschauen, wie das ist, wie ich auf null prüfe.
Andy Grunwald (00:53:50 - 00:55:31)
Genau, also das ist z.B. ein klassisches Problem. Man kann ja nicht schreiben ist gleich null. Also man kann schon in MySQL z.B. aber es kommt halt ein Blödsinn raus, sondern man muss is, also englische Wort ist is schreiben und dann is null, damit du das wirklich prüfen kannst. Und das kommt natürlich genau aus dem Gedanken heraus, dass du eben einen ganz speziellen Wert hast in einer Spalte, der eben bedeutet, du kennst das Datum nicht, du kennst den Wert eigentlich nicht. Was natürlich beim Speichern von Werten absolut Sinn macht. Das Problem ist, wenn du damit arbeiten musst, zieht das natürlich überall ein Rattenschwanz nach. Du musst dir überlegen, was mache ich denn mit diesen null Wellen, null Values? Muss ich die ersetzen? Ignoriere die? Was ist, wenn du ein Group by machst, wenn du ein Sum machst, werden da die Nullwerte mitgezählt, werden sie nicht mitgezählt? Du musst jedes Mal nachschauen bei irgendeinem Count, werden da jetzt die null Values mitgezählt oder nicht? Oder mir geht es zumindest oft so. Also da hängt extrem viel dran und das macht es natürlich alles komplizierter, aber man braucht die Information meiner Meinung nach in der Datenbank. Also es ist ganz schwierig, so eine Information nicht abzubilden, weil es halt einen Unterschied gibt, ob du den Wert kennst oder nicht kennst. Und ich hab mir eigentlich gedacht, das ist schon gelöstes Problem, aber gerade kürzlich, wie ich auf der Fosstim war, war ich in einem Vortrag zu Apache Iceberg und die kümmern sich auch gerade um das Thema, wie sie mit null Values umgehen. Und ich glaube, es ist nicht in der aktuellsten Version drei, weil sie planen, sie in die nächste Version zu bringen, dass sie da beim Speichern oder beim Lesen, dass du da Default Values einstellen kannst, die dann irgendwie mit den null Values dementsprechend umgehen, damit die Werte auch immer gesetzt sind, weil natürlich in jeder Berechnung du sonst in irgendeiner Form diesen Sonder Case irgendwie immer berücksichtigen musst. Und das macht es eigentlich so kompliziert.
Wolfi Gassler (00:55:31 - 00:56:16)
Ja gut, aber die reale Welt hat ja die Abbildung. Also nehmen wir mal das Beispiel, du hast jetzt irgendwie Tages Statistiken über etwas, weiß ich jetzt nicht, du hast jetzt irgendwie einen Supermarkt und oder mehrere Supermärkte und du hast halt eine Tabelle, wo pro Tag die Statistiken reinkommen, wie viele Kunden sind reingegangen, wie viele Kunden sind rausgegangen, wie viel Waren sind verkauft, wie viele Waren wurden zurückgegeben oder ähnliches. Und natürlich kannst du sagen, okay, ich zähle die ganzen Daten mit und wenn der Tag vorbei ist, dann schreibe ich den row für den vorherigen Tag. Du kannst aber auch die Daten einfach on the get go schreiben während des Tages und dann z.b. wie viel Sachen zurückgegeben wurden sind. Kann ja sein, dass das der Prozess wirklich ist, dass die Supermarkt Mitarbeiter dann alle Waren erst am Ende des Tages zählen und dann kommt der Wert halt erst später. Also ich meine, das bildet ja schon irgendwie den realen wert ab oder die reale Welt.
Andy Grunwald (00:56:16 - 00:56:45)
Chamberlain, der Miterfinder von SQL, sagt auch heute noch, es ist nicht ideal, aber jede Alternative, die er bisher gesehen hat, ist noch schlechter oder ist auch nicht ideal. Also er meint auch, es gibt da kein gutes System oder er hat auch keines noch kennengelernt. Und ich glaube auch, es ist die Realität, man muss irgendwie damit umgehen können. Und im Data Science Bereich kann man vielleicht besser damit umgehen mit irgendeinem Apache Iceberg Modell, aber in einer klassischen Datenbank, wo sie wirklich um Hardcore Werte geht, muss sie das irgendwie mit speichern. Ganz klar.
Wolfi Gassler (00:56:45 - 00:57:43)
Genug Geschichte, kommen wir mal in die Gegenwart. Wie im Intro schon, SQL spielt bei den populärsten Programmiersprachen ganz oben mit. Und die meistgenutzten Datenbanken, zumindest nach DB Engines Com, sind inzwischen auch Oracle, MySQL, MS SQL Server und Postgres. Und da fragt man sich doch schon, okay, was hat denn die ganze Sache so erfolgreich gemacht? Und da muss man schon sagen, der Mr. Cod hat damals eine ganze Menge richtig gemacht. Also er hat einfach mal eine richtig, richtig, richtig gute Idee gehabt mit seinem relationalen Datenmodell. Dann Open Source Research hat, glaube ich, haben wir ja schon initial gesagt, Stonebreaker und COD, die haben sich gegenseitig befeuert. Und Bachmann natürlich auch, muss man auch, also ihm muss man leider, also nicht leider, ihm muss man auch Credit zurechnen, weil diese ganze Debatte, die dann natürlich Kurt und Bachmann hatten auf dieser Konferenz 1974, da wo die sich mal ein bisschen gezankt haben in der Debatte, die hat die ganze Sache natürlich auch befeuert. Also das gehörte dazu.
Andy Grunwald (00:57:43 - 00:57:48)
Aber was glaubst du, warum es immer noch genutzt wird? Es könnte ja auch Alternativen geben in der Zwischenzeit.
Wolfi Gassler (00:57:48 - 00:58:51)
Ich bin mir gar nicht sicher, ob es da einen Grund gibt, aber ich glaube, da gibt es mehrere Gründe. Ich glaube die Einfachheit, also ich glaube SQL, dass es leicht zu verständlich ist und der englische Sprache angelehnt ist, glaube ich, ein Key Feature, dann denke ich auch, dass zumindest damals da keine Patent Trolle oder Trademark Issues unterwegs waren. Vielleicht bis auf diesen Namen Sequel mit dieser Flugzeugfirma. Aber das ist noch zu verkraften. Und vielleicht einfach, weil es halt gut funktioniert hat. Also ich meine, viele große Firmen, die haben die ganze Sache 1970, 1980 eingeführt. Wenn wir Glück haben, ziemlich viele dieser großen Firmen leben noch. Das bedeutet, die haben Legacy Systeme. Wie ist der Spruch? Legacy verdient das Geld. Das bedeutet, die haben heute noch SQL Datenbanken. Ja, und ich glaube, dass die Standards mit ANSI und NIST auch eine ganze Menge dazu beigetragen haben, ziemlich früh. Also Kombination aus allem und Open Source Implementierung sind natürlich enorm hohe Qualität aktuell. Und Postgres ganz vorne dabei, wenn die sogar Oracle so ein bisschen in Revenue ablaufen. Ja, ich glaube, es gibt nicht den Grund, ich glaube, es gibt etliche Gründe. Wie siehst du das?
Andy Grunwald (00:58:51 - 01:00:34)
Ja, also ziemlich, ziemlich ähnlich. Genau, was du gesagt hast, einfach von Grund auf schon die offene Kommunikation mit System r, mit Oracle hat sich das einfach schon breit damals entwickelt. Dann ist es noch breiter geworden mit der Open Source Welt. Das heißt, wenn du schon mal so eine Marktmacht hast, dann ist es natürlich super schwer wegzukommen. Und die ganzen NoSQL Datenbanken haben es ja versucht mit ihrer eigenen Anfragesprache, mit einer simpleren Anfragesprache, vielleicht jetzt speziell für dokumentenbasierte Datenbanken. Aber auch da war dann die Standardisierung eigentlich ganz schlau. Es sind immer mehr Dinge dazugekommen zum SQL Standard. Also sie haben dann XML eingeführt, temporale Datenbanken, die ganzen JSON Möglichkeiten, dass man wirklich wie Dokument basiert arbeitet. Commentable Expressions natürlich sind auch ein großer Boost gewesen für den ganzen Data Science Bereich, würde ich mal sagen. Ganz allgemein, OLAP hat natürlich einen großen Stellenwert in der Datenbank, also die Analytical Queries. Und da hat man natürlich dann auch Rollup Cube, diese Operatoren eingeführt, um eben auch analytisch mit Daten umgehen zu können. Jetzt ganz neu gibt es ein Property Graph Query Teil im neuesten Standard, der dann wirklich Richtung Graph Datenbanken geht. Auch da hat man das mit reingenommen. Also ich glaube auch, es ist eine Kombination aus Marktmacht und auch der Standardisierung, die Schlauch vorangeht. Und wie du sagst, also die Einfachheit ist unschlagbar, weil das kannst du auch nicht technischen Leuten relativ einfach beibringen, würde ich mal sagen. Also deinem Versicherungsanalysten, der schafft es auch, das irgendwie zu lernen. Und darum ist es, glaube ich, einfach beliebt, die Flexibilität, Einfachheit, aber gleichzeitig sehr mächtig, natürlich auch durch die Extensions, die es gibt mittlerweile.
Wolfi Gassler (01:00:34 - 01:01:55)
Ich möchte nur sagen, dass du auch in Excel SQL Queries schreiben kannst. Es gibt in Excel eine Funktion, da kannst du SQL schreiben und dann über Tabellen, weil das ist ja nichts anderes. Excel als Spreadsheet ist ja eine Tabelle, eine relationale Tabelle. Und man muss auch sagen, Excel ist auch der größte Konkurrent von jedem Datenbankhersteller, immer noch. Und ich denke, es wird auch noch eine ganze Zeit lang bleiben. Was mich aber gerade so beschäftigt, ist die in der heutigen Zeit, denkst du, das, was da 1970, 1974, 1976 passiert ist, diese offene Forschung, Oracle steht daneben, schaut sich das an, baut das nach, erstes kommerzielles Ding, Research Produkt, blablabla. Wäre heute auch so machbar oder hat sich die Welt einfach verändert? Ich meine, technologietechnisch sind wir ganz vorne, oder sind wir, sind wir deutlich weiterentwickelt. Es ist viel leichter, solche Systeme zu bauen. Man hat etliche Hilfssysteme und so weiter. Denn besonders, wenn man halt so von den Open Source Datenbanken jetzt mal so ausgeht, die dann Lizenzwechsel gemacht haben, weil Amazon das ganze missjust hat mit Elastic z.B. oder mit Redis oder jetzt mit OpenAI, geschlossene Research und dann kommt Deep Seek und trainiert sogar auf OpenAI Daten. Also verstehst du, da ist so ein bisschen mehr Geld im Spiel, mehr Grief, mehr Gier, würde ich vielleicht sagen. Deswegen frage ich mich, wird sowas nochmal, ist sowas nochmal replizierbar in der heutigen Zeit?
Andy Grunwald (01:01:56 - 01:04:02)
Ich glaube sehr wohl. Und auch wenn man jetzt sich überlegt, die Wissenschaftskommunikation von damals, die ja wirklich nur über Papers funktioniert hat, die ist ja viel schnelllebiger geworden. Ich kann heutzutage nachschauen, was ist in Japan veröffentlicht worden, damals hat es nicht funktioniert. Also da gibt es ja auch ganz viele Beispiele, auch in der Datenbankwelt, wo teilweise Papers veröffentlicht wurden innerhalb von einem Jahr. Das eine in Japan, das andere in Europa, die fast das gleiche beschreiben, aber die haben einfach keine Ahnung voneinander gehabt. Und das geht halt jetzt viel schneller. Das heißt, die Wissenschaft kann schneller arbeiten, es ist alles viel offener. Open Source ist ein viel größeres Thema. Wenn du anschaust, die ganzen neuen Datenbanken, die so auf den Markt kommen, da sind ganz viele Open Source Datenbanken dabei, weil du heutzutage es fast nicht mehr kommerziell machen kannst. Da hat sich viel geändert. Insofern glaube ich schon, dass das geht. Aber natürlich, wenn du es jetzt im SQL Sinne betrachtest, wenn du jetzt SQL ablösen willst, das ist natürlich eine schwierige Sache, weil die Marktmacht einfach so hoch ist, die Abdeckung so breit ist, dass es fast nicht mehr möglich ist, aber die grundsätzliche Idee, sowas zu machen, glaube, die wird wissenschaftlich schon funktionieren. Und es ist ja auch ganz interessant, ich habe mir gedacht, gibt es irgendwie eine ähnliche Entwicklung, die so Abfragesprachen mäßig abgelaufen ist? Weil die ursprüngliche Idee war ja auch, von den hierarchischen Modellen auf die relationalen umzusteigen, weil man eine allgemeine Abfragesprache hatte. Also bei den hierarchischen Datenbanken, da war der Code noch an die Daten mehr oder weniger geknüpft. Also man hat da so kleine Prozeduren quasi geschrieben, die dann auf den Daten ausgeführt wurden. Und die relationale Welt war dann eine komplette Abstraktion, dass ich Daten habe und verschiedene Applikationen auf dieselben Daten zugreifen können. Also so klassisch eine API. Und wenn du heute z.B. auf die Rest APIs blickst, dann sind die ja sehr starr und da gibt es ja durch GraphQL auch die Bewegung, das dynamischer zu machen, dass du wirklich die API von den Daten trennst, dass du wirklich Anfragen senden kannst. Und das ist vielleicht so eine ähnliche Entwicklung wie mit den relationalen Modellen, die jetzt in der aktuellen Welt stattfindet.
Wolfi Gassler (01:04:03 - 01:04:29)
Und mit diesem Gedankenexperiment entlassen wir euch in die Nacht, sofern du diese Podcast Episode jetzt nicht abends im Bett hörst zum Einschlafen. Wenn doch, dann spreche ich gerade zu deinem Unterbewusstsein und vielleicht träumst du jetzt gleich von der nächsten Datenbankentwicklung und von der nächsten einfachen Abfragesprache. Wenn du bis hierhin gehört hast, vielen lieben Dank. Wenn du eins mitnehmen solltest, dann woher der Name Postgre kommt oder wie Oracle eigentlich zu seiner ersten relationalen Datenbank kam. Vielen lieben Dank, Dr. Wolfgang.
Andy Grunwald (01:04:29 - 01:04:33)
Moment, bevor wir abschließen, wie viel Turing Award Gewinne haben wir jetzt besprochen?
Wolfi Gassler (01:04:33 - 01:04:36)
Cott hat einen Touring Award bekommen.
Andy Grunwald (01:04:36 - 01:04:36)
Bachmann?
Wolfi Gassler (01:04:36 - 01:04:44)
Bachmann hat einen bekommen, hat Stonebreaker einen bekommen, natürlich haben wir drei noch mehr haben wir nicht besprochen, glaube ich. Aber schon hart.
Andy Grunwald (01:04:44 - 01:04:48)
Also so frühstückt man Turing Gewinner ab in einer Episode.
Wolfi Gassler (01:04:48 - 01:04:57)
Falls du also einen Turing Award gewinnen möchtest, würde ich mich an deiner Stelle auf Datenbank konzentrieren. Anscheinend hat man da ein ganz gutes.
Andy Grunwald (01:04:57 - 01:05:00)
Ich glaube, es gibt noch einige andere auch aus dem Datenbankumfeld.
Wolfi Gassler (01:05:00 - 01:05:08)
Das stimmt, ja, das war's von uns. Wir hoffen, du hast ein bisschen was gelernt oder hat es auch so spaß, so wie wir. Vielen lieben Dank und bis zum nächsten Mal.
Andy Grunwald (01:05:08 - 01:05:09)
Bye bye. Ciao.