AW: AW: AW: [Allegro] Datenimport & Nachtrag
Bernhard Eversberg
ev at biblio.tu-bs.de
Mi Apr 2 08:28:01 CEST 2008
Thomas Fischer schrieb:
>
> Ist es nicht so, dass update für jeden Datensatz das folgende macht:
> 1. Primärschlüssel berechnen
> 2. Nachsehen, ob der in der Datenbank schon da ist
> 3a. Wenn ja, Datensatz nach angegebenen Regeln (u bzw. f) einmischen
> 4a. Registereinträge an Veränderung anpassen
> 3b. Wenn nein, falls notwendig eine Datensatznummer erzeugen
> 4b. Den Datensatz in die Datenbank kopieren und die nötigen Registereinträge
> erzeugen
Ja.
>
> Ich dachte, dass im Falle b) der letzte Schritt der aufwendigste und mit
> index identisch ist.
Aufwendig ja, mit INDEX.EXE identisch nein. Nur die _Erzeugung_ der
Schlüssel, d.h. die Abarbeitung der Parameter, ist identisch, das
_Einsortieren_ läuft total anders. INDEX.EXE erzeugt ja die Indexdatei
neu, das tut es seriell nach Vorsortierung des gesamten Materials,
während alle anderen Programme in den _vorhandenen_ Index einordnen
müssen, und das ist mit VIEL mehr Daten- und Plattenbewegung verbunden,
weil nicht seriell möglich, sondern nur mit "random access" incl.
locking usw. Das setzt einer Beschleunigung enge Grenzen.
> (In Trick 59 steht: "... die Anzahl der Schlüssel ist nämlich der
> Haupt-Zeitfaktor beim Abspeichern".)
Eben, beim Abspeichern, nicht so sehr beim Erzeugen. Sie sehen hier
wieder, wie glasklar und haarklein man alles sagen muß, als
Programmierer, damit Anwender (ohne Einblick in die Programme) wirklich
keine Chance zum Mißverständnis haben, denn sonst nutzen sie die.
> Bei meinem letzten Großimporten (vor zwei Jahren) habe ich die Daten mit
> index eingelesen und die Datensatznummern mit einer Batchdatei und import
> (über die Exportparameter) erzeugt; ich hatte gehofft, dass das heute
> einfacher ginge.
>
Nachträglich Nummern erzeugen kann man auch mit FLEX (einfach den Satz
einlesen und wieder speichern, wenn er keine #00 hat), aber das ist
nicht der ganz große Zeitfaktor.
B.E.
Mehr Informationen über die Mailingliste Allegro