Aufbau grosser Datenbanken

[Thomas Berger]

Liebe Frau Koczian,

> >zumindest sollte die Tendenz steigen, einen eventuellen Crash
> >auf die Indexierung zu verschieben, weg vom Update...
> 
> Und dann hat man wenigstens brauchbare Grunddateien, war das der Gedanke?

Vermutlich meinen wir dasselbe: Man kann dann an der Indexierungs-
Stelle noch einmal aufsetzen und schauen, ob es an derselben
Stelle Crasht (Vorteil mit v22.2: aktuelle .ALD wird am Schirm
des oefteren angezeigt)

 
> Der Aufbau nach dieser Methode ist jetzt fertig, wirklich _viel_ schneller
> (23 statt 40 Stunden).

Nicht besonders beeindruckend. Nehmen Sie fuers Update doch
eine .api, die nur den Primaerschluessel bildet (moeglichst nicht
nur alle anderen ak-Befehle auskommentieren, sondern wirklich
nur die benoetigten Anweisungen drinlassen).


> Aber jetzt sind es ploetzlich viel _weniger_ .ald-Dateien, aus den gleichen
> Grunddaten, obgleich jetzt massenhaft Fuellzeichen drin sind, und obgleich
> ich vorher nach dem update-Lauf entlueftet habe. Kann mir das jemand
> erklaeren? Der letzte Satz der Ursprungsdaten ist jedenfalls da und ok.

Interessant. Vor allem wo da ja noch eine Unklarheit zurueckgeblieben
war, naemlich dass ich behauptete, alles deute darauf hin, dass ohne
-N0 gearbeitet worden war, Sie aber sagten "mit". Es kann natuerlich
sein, dass das Dazumischen Schluessel benoetigte, die durch die
- at 1-Indexierung nicht gebildet werden, das waere schlimm, muesste
sich aber aus UPRO auslesen lassen (new bzw. ignored = 0: gut).

Wenn vorher massenhaft Fuellzeichen drin waren, und zwar massenhaft
genug, so sind diese ja nun weitgehend aufgebraucht. Wenn Sie diese
Datenbank nun entlueften, wachsen die .ALD-Dateien bestimmt um
100 MB (die Monster-Fuellzeichenzahl vorausgesetzt), kommt es dann
wieder hin?

 
> Um die Fuellzeichen wieder loszuwerden, waere ein Neuaufbau mit einer
> Konfiguration ohne Fuellzeichen statt der Neuindexierung am Ende noetig,
> sehe ich das richtig? Das wuerde zwar einen Teil der Zeitersparnis
> auffressen, aber da es um Nur-Lesen-Datenbanken fuer CD's geht, scheint es
> mir besser.

Eine Zweistufige Indexierung mit - at 1 und dann - at 2 sollten Sie sowieso
machen, ob der Lauf - at 1 mit -fi0 oder mit -f70 gemacht wird, bedeutet
einen gewissen Zeitunterschied, aber nicht mehr als ein paar Minuten,
selbst bei dieser Menge.


> >Was nun "primkey" sowohl bei a99 als auch avanti, sowie den
> >Update-Primaerschluessel bei avanti angeht, muesste es getestet
> >werden: Fruehere Avanti-Versionen hatten #-@ fest verdrahtet, dem
> >ist m.E. aber nicht mehr so. Die "family"-Befehle (bzw. auch download
> >fam) bei a99 kann man impfen (d.h. ist #09 vorhanden, muss die
> >"family" nicht anhand des primkey gebildet werden, sondern mit dem
> >Anfang von #09), das habe ich schon irgendwo mal so gemacht.
> >Das Analoge bei avanti funktioniert theoretisch ja genauso wie
> >bei a99, ist aber praktisch bestimmt noch nie ausprobiert worden.
> 
> Wie "impft" man die family-Befehle?

ueber die iV natuerlich (vgl. xfamily.rtf) Daher hat mich das
"Himmelfahrtskommando" 2002 etwas ueberrascht, wo eine aehnliche
Funktionalitaet noch einmal unter dem Namen "qrix" realisiert
wurde...

viele Gruesse
Thomas Berger