<!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>