Aufbau grosser Datenbanken

Thomas Berger ThB at gymel.com
Mi Jan 22 13:42:59 CET 2003


Liebe Frau Koczian,

> >jetzt meine Antworten zu Ihren Fragen am Ende der eMail.
> >Das File-System ist NTFS.
> >Zu den Datümern der Dateien läßt sich nichts genaueres
> >sagen. Wir haben immer mit den gleichen Rohdaten getestet.
> >Datum der *.exe-Dateien :
> >index.exe : 4.5.00
> >grix.exe : 13.4.00
> >update.exe : 7.7.00
> 
> Meine erste Reaktion: da muss man gar nicht weiterforschen. Aber: der
> Datenbankaufbau fand lokal am Einzelplatz statt, und die wichtigsten
> Veraenderungen in Sachen groesserer Sicherheit bezogen sich in erster Linie
> auf den Netzbetrieb, oder stimmt das nicht?

Es gab auch die Hochsetzung von 500 auf 1000 Schluessel und evtl.
Verbesserungen bei der intern nutzbaren Speichermenge fuer 
Schluessel (INDEX nun etwa unbeschraenkt). 

 
> Kann man eigentlich davon ausgehen, dass die vorgeschlagenen Aktionen:
> 
> - Fuellzeichen wg. Update
> - erst Primaerschluessel indexieren, dann Update, dann Reindexieren mit
> allen Schluesseln
> 
> nicht nur der Beschleunigung dienen, sondern den Aufbau sicherer machen?
> Darum geht es naemlich, die Dauer ist durchaus sekundaer.

zumindest sollte die Tendenz steigen, einen eventuellen Crash
auf die Indexierung zu verschieben, weg vom Update...

 
> Die zwei Indexlaeufe mit zwischengeschobenem Update funktionieren uebrigens
> erst, seit ich die Indexparameter geaendert habe, so dass nicht mehr, wie
> es Standard ist, #09 Primaerschluessel ist, sondern #00. Denn die
> Lokalsaetze fuer Baende mehrbaendiger Werke haben die #00 des Titelsatzes,
> also hier des Einzelbandes, als Verknuepfung. Gehe ich recht in der
> Annahme, dass die einzige Schwierigkeit, die man sich damit potentiell
> zuzieht, bei der Anwendung des family-Befehls in Flexen und Avanti-Jobs
> liegt? Die #00 ist mir sowieso sympathischer, denn bei der #09 kann es
> Mehrdeutigkeit geben (DDB-Daten!).

Hier sprechen Sie ein lange unbeachtet gebliebenes Problemfeld 
an: Die Standardparameter setzen voraus, dass ueber #09 verknuepfte
Saetze keine eigene #00 brauchen, dass also eigentlich #09 nichts
anderes als ein Ersatz fuer #00 ist. Das muessen sie auch, weil
naemlich sonst die b/B-Tasten in PRESTO nicht funktionieren.
Die b/B-Tasten haengen zwingend an der Marke #-@, anderswo habe
ich erfolgreich die Primaerschluesselberechnung auf mir genehme
Weise bei einer anderen Sprungmarke erledigt und eine nicht-
angesprungene Marke #-@ nur fuer b/B bereitgestellt.

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.

viele Gruesse
Thomas Berger




Mehr Informationen über die Mailingliste Allegro