Max. Anzahl Datensaetze

[Bernhard Eversberg]

Aufbohrung geplant: Maximal moegliche Anzahl Datensaetze


Auf dem Expertentreffen gab es u.a. eine Diskussion ueber Fragen der
Kapazitaetsgrenzen. Es ergab sich, dass wohl am ehesten die Zahl der 
tatsaechlich moeglichen Datensaetze zum Problem werden koennte.

Zwar kann man mit 4 Byte gut 4 Milliarden Datensaetze nummerieren,
doch ist das eine illusorische Zahl, weil es nur 255 Dateien (Typ .ALD)
mit bis zu 16.000.000 Byte geben kann. Hat man z.B. Saetze mit durchschnitt-
lich 500 Byte, kommt man damit auf  "nur" ca. 8 Millionen Datensaetze. 

Kollege Berger machte einen interessanten Vorschlag, wie man ohne grossen
Aufwand diese Grenze stark erhoehen koennte. Die Pruefung des
Vorschlags ergab, dass er wohl tatsaechlich ohne nennenswerte Neben-
wirkungen realisierbar ist. Insbesondere waere die Sache leistungsneutral,
d.h. es gaebe keinen Geschwindigkeitsverlust.
Noch haben wir das nicht in Angriff genommen, sondern wollen die Sache erst
noch mal zur Diskussion stellen - vielleicht gibt es ja noch Aspekte, 
die wir uebersehen haben. Oder andere Ideen.

So sieht der von uns weiter praezisierte Berger-Vorschlag aus:
Momentan ist in der TBL der Anfangspunkt (sog. "Offset") eines jeden Daten-
satzes mit 3 Byte codiert, wobei ein Datensatz mit seiner exakten Laenge
abgespeichert wird, ohne ein einziges Byte mehr - wenn man keine Fuellzeichen
zulaesst. Wenn man nun festlegen wuerde, dass die Laenge eines Datensatzes
immer ein Vielfaches von N sein muss (N = 2, 3, ...), koennte man die N-fache
Zahl von Saetzen haben. Es muesste lediglich in der TBL statt der tatsaech-
lichen Position die durch  N geteilte Zahl gespeichert werden. Mit N = 3
kaeme man also schon auf 24 Millionen Saetze, wobei jeder einzelne Satz
hoechstens 2 Byte (Fuellzeichen) mehr haette als er braucht, denn die
einzelne Datei koennte dann 48 statt 16 MB gross werden. Usw.

Die Pruefung ergab, dass tatsaechlich nur sehr wenige Stellen (weniger als
10) in den Programmen zu bearbeiten waeren. Es liegt nahe, die Zahl N in
den Indexparametern zu verankern, z.B. mit einem neuen Befehl ii=N.
Fehlt dieser, wuerden die erweiterten Programme so arbeiten wie die alten.
D.h. man muesste an "alten" Datenbanken nichts aendern. Die Umstellung
einer alten Datenbank wuerde natuerlich bedeuten, dass man eine Index-
erneuerung mit Modus 7 vornehmen muesste. (Jeder Satz hat danach eine
durch N teilbare Laenge.)
Zusaetzlich koennte N an der Position 1 der TBL stehen (wo jetzt immer 3 
steht, aber nichts zu bedeuten hat) Dann waere der Wert N ohne Einblick in
die API zu erkennen.
Betroffen sind die Programme INDEX, PRESTO, UPDATE und SRCH (wg. Nachladen),
ferner 2 Module der Klassenbibliothek (gueltig fuer a99, alcarta, avanti 
...).
Mit PRESTO sind auch APAC und Derivate sowie ORDER und aLF betroffen, diese
verwenden aber dieselben Module wie PRESTO, muessen also dann nur neu
kompiliert, nicht ueberarbeitet werden.
Aber wie gesagt: wer den Befehl ii nicht einbaut, kann die neuen Programme
verwenden, ohne irgendwas tun zu muessen. Nur die vorlaeufig sehr wenigen
Projekte, die ii einsetzen wuerden, muessten dann aufpassen, nur noch die
neuen Programme zu verwenden - die alten koennten auf eine aufgebohrte
Datenbank nicht korrekt zugreifen (bis auf INDEX und SRCH, letzteres aber 
ohne Nachladung)!

Wie gesagt: programmiert ist noch nichts. Wird dem Vorschlag ohne weitere
Modifikation zugestimmt, koennte die Realisierung sehr schnell gehen.

Meinungsaeusserungen sind erbeten.

Bernhard Eversberg
Universitaetsbibliothek, Postf. 3329, 
D-38023 Braunschweig, Germany
Tel.  +49 531 391-5026 , -5011 , FAX  -5836
e-mail  B.Eversberg at tu-bs.de