Aufbau großer Datenbanken

[Thomas Berger]

Liebe Frau Koczian,

> At 15:21 14.01.03 +0100, you wrote:
> >das ist der "second run" index -fa, der "verewigt" sich
> >durch einen Datummsstempel an der Datei protok und evtl.
> >ein bis zwei zusaetzlichen Zeilen dortselbst:
> >
> >7 relations expanded
> >299 not expanded
> 
> D.h. dann muesste eigentlich protok einen spaeteren Zeitstempel haben als
> protoq? Hat es nicht. Aber, wie gesagt, es gibt in Wirklichkeit gar keine
> Stammsaetze. Wahrscheinlich waere es gar nicht dumm, i5 auszukommentieren.


Vermutlich wird der 2nd run nur ausgeloest, wenn i4 in der
.api gesetzt ist...


> > > > > Die Groesse der bei Index entstehenden Zwischendateien richtet sich
> > nach
> > > > > dem verfuegbaren Arbeitsspeicher und ist nicht einstellbar, habe
> > ich das
> > > > > richtig verstanden?
> > > >
> > > >Ja. Sind diese aber sehr klein, waere das schlimm. Ca. 70-80kB sollten
> > > >sie normalerweise haben.
> > >
> > > Wenn ich die Groesse der .adx-Datei durch die Anzahl der ii-Dateien teile
> > > (aus protok), dann sieht es aus, als seien sie tatsaechlich kleiner gewesen
> > > (55 kB). Aber stimmt diese Rechnung?
> >
> >Nein. Aber immerhin waren sie >= 55kB, was eher beruhigend ist.
> 
> ??? Wenn meine Rechnung nicht stimmt, dann wissen wir das doch gar nicht?
> Oder gibt die Division grundsaetzlich einen Wert, der jedenfalls nicht
> groesser ist als die wirkliche Groesse der ii-Dateien?
> 
> .adx-Datei: 322.630 kB
> Anzahl ii-Dateien lt. protok: 5802.

Beim Zusammenmischen der ii-Dateien gibt es ja ab und zu :-)
die Situation, dass gleiche Schluessel fuer verschiedene Saetze
zusammenfallen, daher nimmt im Lauf der Verarbeitung die "Gesamt-
Masse" der Dateien (kulminierend in der .ADX) tendenziell ab.


 
> >D.h. Sie benutzen globale Manipulation beim UPDATE,
> >um die bereits indexierten Titelsaetze um die Lokalinformationen
> >zu ergaenzen? Und die Lokalinformation kommt ggfls. aus mehreren(!),
> >bereits umgewandelten und in der .alg-Datei vorhandenen
> >Lokalsaetzen und kumuliert?
> 
> Keine globale Manipulation, sondern -fm41. Ansonsten genau so.

Schwer vorstellbar: Gibt es doch nur einen Lokalsatz pro Titel
oder werden die Lokal-Informationen beim Import irgendwie "entzerrt",
denn sonst muessten sie sich doch ueberschreiben?

 
> >- Anwendervariable der Globalen Manipulation sind in
> >   Konflikt mit denen aus der .api
> >- Unsauberkeiten in der globalen Manipulation / .api fuehren
> >   zu nicht geloeschten Anwendervariablen, die sich zu einem
> >   Speicherproblem aufschaukeln.
> 
> Das kann's m.E. eigentlich nicht sein. Titel- und Lokaldaten kommen in
> getrennten Dateien an (beides MAB2), werden getrennt importiert und
> duerften nach dem Import nach bestem Wissen und Gewissen nur ordentliche
> Kategorien enthalten, keine Anwendervariablen. Wenn dann Index und Update
> starten, dann koennen doch Anwendervariablen aus den Importparametern keine
> Rolle mehr spielen? Bezueglich Unsauberkeiten in der .api kann ich
> natuerlich keine heiligen Eide schwoeren. Ich glaube nicht, dass ich selber
> welche hineingebracht habe; beim Schlagwortketten-Register habe ich bei
> Ihnen abgekupfert, habe das aber wenigstens so einigermassen verstanden.
> Aber ansonsten bleiben mir die Standardparameter ewige Raetsel.

Wenn keine globale Manipulation im Spiel ist, dann sind die einzigen
beteiligten Anwendervariablen diejenigen der .api. Da werden
normalerweise
alle geloescht, es gab dieses Jahr aber einen Fall, wo dies nicht
so war (zu besichtigen an der Demodatenbank von v 22.0)

 
> Gibt es einen besseren Weg als Index + Update? Dass ein von mir
> geschriebenes Perl-Skript, das die Lokaldaten vor dem Import in die
> Titeldaten einmischt, etwas anderes tun koennte als die ganze Aktion viel
> schlimmer zu bremsen als Update es tut, nebst wahrscheinlich zusaetzlichen
> Fehlern und Unsicherheiten, scheint mir mehr als unwahrscheinlich.

Nein, ich halte es auch nicht fuer wahrscheinlich, dass ein Perlskript
langsamer und schaedlicher sein sollte als allegro :-).

Trotz Spezialindexierung ist es bei einem Update unwahrscheinlich,
dass Sie mehr als 50.000 Saetze pro Stunde einmischen koennen.


> (Allenfalls wenn ich ganz sicher sein koennte, dass die Lokalsaetze nach
> der ID-Nr. des zugehoerigen Titelsatzes geordnet kommen - dann vielleicht.)

Ein Sortierprogramm ist Ihr Freund :-)
 

> Ueber separate Lokalsaetze haben die Redaktion und ich gemeinsam am Anfang
> nachgedacht, insgesamt schienen die Nachteile groesser als die Vorteile.

Fuer eine weitgehend "verbundtreue" Datenbank habe ich einmal folgendes
gemacht: Lokalsaetze aufgeloest, dabei jedoch die Bedeutungstragenden
Elemente (lokale Notationen, Grundsignaturen der Freihand-Aufstellung)
in die Titelsaetze ueberfuehrt, Exemplarsaetze beibehalten, dabei jedoch
die bedeutungstragenden Signaturen ebenfalls in die Titelsaetze
ueberfuehrt: Damit konnten mittels Suche ueber die Systematik direkt
die Titel gefunden werden, Standortinformationen hingegen wurden
waehrend der titelanzeige ueber Nachladungen aus den Exemplarsaetzen
herbeigeschafft. Das Aufwendige dabei war das Ueberfuehren der
Notationen (Exemplare haben meist aehnliche Signaturen, Update-
Lieferung bringt Exemplare ggfls. noch einmal), nicht das Erhalten
der Ausgangsstruktur :-)