<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 5.50.4134.600" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>Lieber Herr Hoeppner,</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>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ß.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>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.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>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.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>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 </FONT><FONT face=Arial 
size=2>Konzeptionen als überlegenswert erweist bzw. daß es als 
Gedankenexperiment neue Möglichkeiten eröffnet.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Den Absatz</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV>>Sie meinten, bei flachen Bäumen müßte man den Geschäftsgang 
<BR>>überdenken. Nun ist es aber das Wesen einer Datenbank, dass sie 
<BR>>nur aus einer langen Kette von prinzipiell gleichen Datensätzen 
<BR>>besteht. Das ist nun extrem flach. Da beißt keine Maus den Faden 
<BR>>ab. Es gab früher mal Datenbanken, die die Daten hierarchisch 
<BR>>recht tief speicherten, die waren aber sehr unflexibel. Man ist da 
<BR>>aus guten Gründen von abgegangen.<BR></DIV>
<DIV><FONT face=Arial size=2>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.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>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"</FONT></DIV>
<DIV><FONT face=Arial size=2>machtlos ist, würde man bei XML wenigstens nichts 
verlieren.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Für bibl. Spezifika ließen sich CDATA Passagen oder 
gar ein Entity Baukasten denken.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>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.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>      * * *</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>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.</FONT></DIV>
<DIV><FONT face=Arial size=2>Ich schreibe das lieber selber hin und schaffe 
mir bei Bedarf einen Makro, eine Subroutine usw. </FONT></DIV>
<DIV><FONT face=Arial size=2></FONT><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>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.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>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.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>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.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Gruß</FONT></DIV>
<DIV><FONT face=Arial size=2>R. Henkel</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV></BODY></HTML>