Bloss eine Idee

Do Sep 28 16:18:59 CEST 2000

Lieber Herr Hoeppner,

Es ist ein großer Vorzug von Allegro, daß Raw Devices auch bei großen Datenbanken nicht unbedingt gebraucht werden. Aber das ist m.E. nicht Folge eines bestimmten  Aufbaus der .cLD-Datei, sondern hat mit der ganzen Arbeitsweise zu tun. Ob sich der Zugriff wirklich so sehr verlangsamen würde, wenn pro Kategorie noch ein Start und EndTag dazu käme, kommt mir eher unwahrscheinlich vor, selbst wenn sich sich die Datenbank um 150MB vergrößern würde. Mit anderen Worten, meiner Ansicht nach kommt die Perfomanz von Allegro nicht so sehr von dem gegenwärtigen .cLD-Format, sondern durch die Indexierung bzw. die leichte Auffindbarkeit des einzelnen Datensatzes. Wie man das bei Übergang auf beispielsweise  XML-Files bewahrt, wäre gerade ein Punkt, über den man intensiv nachdenken und dabei vieles erwägen und verwerfen muß.

Daß solche Datenbanken nicht mehr auf CD passen, ist freilich wahr. Aber erstens gibt es ja auch DVD und zweitens könnte ich mir auch jetzt schon Allegro-Datenbanken vorstellen, die  für CD zu groß sind. Auch der baC wird früher oder später mal an die Grenze kommen, soweit ich mich erinnere, ist schon die letzte CD mit einigen Mühen zustande gekommen. Das hängt doch wohl letzten Endes von der "nach oben offenen" Anzahl der Datensätze ab.

Schließlich wird man sich bei einem gewissen Datenvolumen generell nach einer anderen DB-Software umsehen, Allegro kann nicht - und will sicher auch nicht - die ganze Palette der Datenhaltung abdecken.

Im übrigen ist ja das Datenbankformat für sich genommen eigentlich nicht der springende Punkt, eine Fixierung darauf würde diese kleine Diskussion abdriften lassen. Man gewinnt nichts dadurch, wenn bloß die .cLD Datei künftig wie XML aussieht. Es könnte doch aber immerhin sein, daß sich dies im Zuge anderer Konzeptionen als überlegenswert erweist bzw. daß es als Gedankenexperiment neue Möglichkeiten eröffnet.

Den Absatz

>Sie meinten, bei flachen Bäumen müßte man den Geschäftsgang 
>überdenken. Nun ist es aber das Wesen einer Datenbank, dass sie 
>nur aus einer langen Kette von prinzipiell gleichen Datensätzen 
>besteht. Das ist nun extrem flach. Da beißt keine Maus den Faden 
>ab. Es gab früher mal Datenbanken, die die Daten hierarchisch 
>recht tief speicherten, die waren aber sehr unflexibel. Man ist da 
>aus guten Gründen von abgegangen.

verstehe ich ehrlich gesagt nicht recht. Ich habe mich wohl irgendwie mißverständlich ausgedrückt. Ich zielte ja gerade auf umständliche Hierarchiebildungen und wollte sagen, daß ein stringentes Konzept solche manchmal erübrigt. Daß man von hierarchischen Datenbanken auf Grund von Unflexibilität abgegangen ist, sehe ich nicht als Argument gegen "flache Bäume", sondern eher als eins dafür.

Daß das Hauptproblem bei bibl. Datensätzen die Besetzung der Felder mit korrektem Inhalt ist, sehe ich auch so. Aber da, wie sie sagen, auch Allegro gegenüber einem an die falsche Stelle gestellten "Spion, der mich liebte"
machtlos ist, würde man bei XML wenigstens nichts verlieren.

Für bibl. Spezifika ließen sich CDATA Passagen oder gar ein Entity Baukasten denken.

Es kann nicht darum gehen, daß man sich irgendeinen XML-Werzeugkasten aus auf dem Markt frei oder kostenpflichtig erhältlichen Komponenten zusammenstellt und "Allegro" dran schreibt. Auch mit XML bleibt Allegro meiner Ansicht nach Software, die mit den üblichen Mühen der Konzeption und Programmierung erstellt wird, wobei hier noch die glückliche Situation vorliegt, daß man über eine Anzahl bewährter Konzepte und etliche Erfahrung verfügt. Was sich ändern würde, ist gewissermaßen der Input und der Output.

      * * *

Was nun die von Ihnen angeführten impliziten if-Abfragen, ohne daß man etwas tun müßte, angeht, so bitte ich doch auch einmal die Kehrseite solcher Implikationen in Betracht zu ziehen. Für mein Teil finde ich diese "Seiteneffekte" fürchterlich, weil die natürlich auch da funktionieren, wo man sie gar nicht haben will und deshalb auch nicht im Auge hat.
Ich schreibe das lieber selber hin und schaffe mir bei Bedarf einen Makro, eine Subroutine usw. 

Außerdem bläht die Tendenz, möglichst viele Funktionen implizit in ein Sprachelement zu packen, die Sprache auf, weil man früher oder später natürlich irgendeins braucht, das zwar fast dieselben aber nicht alle Funktionen oder in einer etwas anderen Kombination braucht.  So werden aus Atomen Moleküle und es ist am Ende doch schwieriger, sich 100 Moleküle - von denen jedes auf den ersten Blick dem anderen ziemlich gleich sieht - als 10 Atome zu merken.

Das übliche kommt hinzu: Im Lauf der Zeit vergessen sowohl Schöpfer wie Anwender die genaue Funktion dieser Moleküle, und kommt dann ein neues dazu, dann treten Ungereimtheiten auf - das eine beginnt einen String bei 0, das andere bei 1, oder je nach dem ab 4 oder 5 zu zählen, in diesem String darf dieses nicht, in jenem jenes nicht enthalten sein usw. usf.

Daß manches "manchmal sehr praktisch ist", tröstet einen nicht immer über Stunden hinweg, wo man wieder einmal einer solchen Implikation zum Opfer gefallen ist. Fehlersuche und Testanordnungen wird durch solche hineinspukenden Erleichterungen eben auch nicht gerade erleichtert.

Gruß
R. Henkel

-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://bibservices.biblio.etc.tu-bs.de/pipermail/allegro/attachments/20000928/3847b1b1/attachment.html>