Bloss eine Idee

Fr Sep 29 09:04:05 CEST 2000

Lieber Herr Henkel,

> 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 stimme ich Ihnen voll zu. Vielleicht haben wir da ein wenig 
aneinander vorbeigeredet. Für das, was mit allegro gemacht wird, ist 
das Ding wirklich nicht schlecht. Sie können aber mit allegro, so wie 
es ist, nie den Durchsatz an Datenveränderungen erzielen, wie es 
für andere Datenbanken notwendig ist. Ich denke da zum Beispiel 
an Banken od. Versicherungen. Die haben es aber mit ganz 
anderen Typen von Daten zu tun. Da finden Sie in einer Datenbank 
nicht so heterogenes Material wie in allegro.

Die Zugriffsgeschwindigkeit würde durch Einführung von xml-Tags 
bestimmt nicht langsamer. Mit ging es um den Platzverbrauch. Als 
ich aufgrund Ihrer Bemerkung das mal mit dem bac grob 
durchkalkulierte war ich doch ein wenig überrascht. Mir ging es 
einzig und allein dabei um die "Platzverschwendung" und nicht um 
die Zugriffsgeschwindigkeit.

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

Richtig, aber momentan sind die DVDs noch nicht soweit verbreitet. 
Wir haben auch mit unserer CD Platzprobleme, weil neben den 
Datenbanken ja noch allerhand anderes Zeuges drauf ist. Wenn wir 
nur DVDs produzieren würden, gäbe es z.Zt. noch viel 
Protestgeschrei. (Es gibt sogar unter den allegro-Nutzern noch 
etliche, deren Rechner noch nichtmal über ein CD-ROM-Laufwerk 
verfügen.)

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

Genau. Trotzdem sehe ich mit allegro und den Daten mit denen wir 
es zu tun haben noch kein Ende der Fahnenstange. Die HBZ-
Download-Datenbank, die Herr Berge mit aufgebaut hat, ist noch 
nicht das Ende. Gut, die wird auch nicht in einer Nacht neuindexiert. 
(Frage an Herrn berge: Wie lange hat der Aufbau gedauert?) Von 
einem schweizer Kollegen, der mit einer Software einer israelischen 
Firma arbeiten muss, habe ich mir sagen lasse, dass dort die 
komplette Neuindexierung bei 1,5 Mio Datensätzen ca. 3 Wochen 
dauern soll. Jedenfalls können die solange nicht mit dem Ding 
arbeiten. Auf der anderen Seite ist allegro sicherlich nicht geeignet, 
dass man damit eine große Verbunddatenbank aufbaut, an der 
gleichzeitig mehrere hundert Leute arbeiten. Dafür ist es ja auch 
nicht gedacht.

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

Genau, die eingesetzten Felder in einer Datenbankanwendung 
haben wirklich nur sehr wenig mit der darunterliegenden 
Datenbanktechnik zu tun. Es gibt ja sogar Leute, die 
bibliographische Daten in relationale Datenbanken zwängen ;-)

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

Ja, so war es auch gemeint.

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

Das sehe ich auch so.

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

Also, es ist ja wohl bekannt, dass ich kein ausgebildeter Bibliothekar 
bin, und RAK steckt mir auch nicht im blut, deshalb meine Frage: 
Können Sie mir da ein Besipiel bitte nennen? Ich hatte den Spion-
Titel gewählt, weil der ein Komma enthält. Und bei allegro jedenfalls 
ist es so, dass die einzige Prüfung in einem Namensfeld die ist, 
dass auf das Vorhandensein eines Kommas getestet wird. Was 
kann man mit XML-Mitteln da noch mehr prüfen? Keine Software 
kann z.Zt. Prüfen, ob das eingegebene wirklich ein Name ist. Gibt 
es vielleicht andere Felder, an denen man das besser deutlich 
machen kann? 

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

Das mit dem Output ginge prinzipiell ja jetzt schon. Es waere 
vielleicht wirklich mal ein lohnedes Projekt, für das A-Schema eine 
DTD und einen XML-Export zu erstellen. Beim Input sind 
Fremddaten wohl auch nicht das große Problem. Wenn man XML 
aber für Konfigurationen einsetzen wollte, da gäbe es für uns was 
zu tun.

> 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. 
> ... (und das folgende)

Das kann ich nicht mit Bausch und Bogen vom Tisch fegen, will ich 
auch nicht. Zumindest in einer Webanwendung kann man das aber 
schon realisieren. Man gibt einfach die Daten im Grundformat mit 
der Parameterdatei e-w aus und läßt das dann von seinem eigenen 
Programm auswerten. Frage in die Runde (sofern dies genügend 
Leute noch mitverfolgen): Wer hat sowas schon mal gemacht und 
kann man sich das mal ansehen? Mich interessiert dabei aber eine 
Umsetzung, die gleichwertige wie die D-1 leistet. Einfache 
tabellarische Ausgaben, wie man sie zum Beispiel in unserem PICA-
Lokalsystem sieht, sind nicht gemeint. Das ist zu trivial.

Viele Grüße
Dierk Hoeppner
Universitaetsbibliothek
Pockelsstr. 13
D-38106 Braunschweig
Germany
Tel: +49-531-391-5066 Fax: -5836
E-Mail: d.hoeppner at tu-bs.de     