>>156347>War zu faul in den Quelltext zu schauen, meine mich aber erinnern zu können, dass Meister Zuse sicher keine "handelsübliche" Datenbank benutzt.
Ja, die ist handgefrickelt. Im Grunde genommen ist das einfach nur ein Speicherabbild mit einem zusätzlichen Journal, um Atomizität zu gewährleisten, falls mal während eines Updates der Strom ausfällt oder so.
Warum handgefrickelt? Dazu kleine Geschichtsstunde: Diätkanal entstand in den ganz früher Anfangsphasen von Kohlkanal, als jener noch vichan einsetzte, bei Cockbox gehostet war, und mit erheblichen Performanzproblemen zu kämpfen hatte. Es wurde damals über einen Umstieg auf Lynxchan nachgedacht, der ja später dann auch erfolgte, aber Zuse war und ist kein Freund von diesem Node+MongoDB-Geraffel (der Kot war zuminest damals auch absolut scheußlich) und es zirkulierte bereits das Mem, man könnte da doch was mit dietlibc, tinyldap und libowfat...
Irgendwann hat Zuse das dann aus einer Laune heraus einfach mal eben schnell an einem Wochenende gemacht (so ungefähr), eigentlich als Witz. Der Anspruch von Diätkanal war eigentlich, so eine Art Anti-Lynxchan sein. Unter anderem deswegen gibt es hier ja auch kein JS, weder server- noch clientseitig. Eigentlich wollte Zuse damals auch stilecht tinyldap als Datenbank nehmen, aber dazu kam es nicht aus folgenden Gründen:
- Zuse kapiert diesen LDAP-Scheiß nicht. Sich in LDAP einzuarbeiten hätte länger gedauert, als das ganze Brett zu programmieren, und hätte keinen Spaß gemacht.
- tinyldap untersützte damals keine Löschvorgänge, war für ein Bilderbrett also absolut ungeeignet.
- Es wurde nach anderen Alternativen gesucht: sqlite war immer noch zu bloatig, hätte den Fußabdruck um Größenordnungen erhöht. (sqlite umfasst alleine ungefähr 250k Zeilen, Diätkanal damals 9k). Und da das Brett natürlich dietlibc verwenden sollte, hätte sqlite natürlich aus der Quelle kompiliert werden müssen. Aber das hätte die Wahrscheinlichkeit, dass irgendwer diese Weichware tatsächlich ausprobiert, extrem verringert, weil niemand mal eben 250k Zeilen auditiert um zu prüfen, dass da nichts böses drin versteckt ist. Zuse wollte ursprünglich eigentlich nur die Weichware zeigen, das zugehörige Brett war gar nicht geplant und sollte eigentlich nur als Demo dienen, weil Zuse dachte, dass sich ohne Lebend-Demo das eh keiner anschaut.
- BerkeleyDB wurde auch noch evaluiert, und Zuse hat sich ein paar Ideen dort abgeschaut, aber es schien einfacher, es einfach selbst zu implementieren.
- Zuse wollte das schon immer mal machen.
- Bei herkömmlichen Datenbanken hat man immer extrem viel Klebe-Kot zwischen der Datenbank und den klientseitigen Strukturen (Stichwort ORM, Active Record, etc.). Diätkanal sollte aber minimalistisch sein (was unter anderem eine möglichest geringe Zeilenanzahl bedeutet) und da schien es am einfachsten, einfach direkt die Strukturen aus dem Arbeitsspeicher wiederzuverwenden und auf die Platte zu schreiben.