Das ist ein Kernstück einer einfachen, aber leistungsfäghigen Datenbank mit variabler Länge der Felder:

Schreiben eines Datensatzes aus einer Matrizenspalte in die Hauptdatei ab Satznummer 4, Schreiben der Anzahl der Datensätze und der Anzahl der Felder pro Datensatz in den 1. Satz der Hauptdatei, Schreiben der Feldbezeichnungen in den 2. Satz der Hauptdatei, Formatieren des 3. Datensatzes (nur bei erstem Schreiben in die Datei), der später dazu dient, zu den Indexdateien zu verweisen.

41110 xx$ = "": FOR ppr% = 1 TO feldanzahl%
41120  feld$ = RIGHT$(STR$(ppr%), LEN(STR$(ppr%)) - 1): feld$ = CHR$(255) + feld$ + CHR$(255)
41130 xx$ = xx$ + feld$ + daten$(1, ppr%)
41150 NEXT ppr%
41170  feld$ = RIGHT$(STR$(feldanzahl% + 1), LEN(STR$(feldanzahl% + 1)) - 1): feld$ = CHR$(255) + feld$ + CHR$(255)
41180 xx$ = xx$ + feld$
41200 LSET all$ = xx$: PUT #4, satz% + 3
41201 RETURN
42000 REM
43000 REM
43110 xx$ = "":FOR ppr% = 1 TO feldanzahl%
43120  feld$ = RIGHT$(STR$(ppr%), LEN(STR$(ppr%)) - 1): feld$ = CHR$(255) + feld$ + CHR$(255)
43130 xx$ = xx$ + feld$ + daten$(2, ppr%)
43150 NEXT ppr%
43170  feld$ = RIGHT$(STR$(feldanzahl% + 1), LEN(STR$(feldanzahl% + 1)) - 1): feld$ = CHR$(255) + feld$ + CHR$(255)
43180 xx$ = xx$ + feld$
43200 lset all$=xx$:put #4,2:
43300 xx$=space$(1024):lset all$=xx$:put #4, 3
43400 close #4:return

01. April 2012: Kleine Einblicke in meine Programmierung und ihre Möglichkeiten.

Dipl.-Kfm. Winfried Sobottka

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Das ist ein weiteres Kernstück der einfachen, aber leistungsfähigen Datenbank: Ein Satz wird anhand der Satznummer gelesen, seine Feldinhalte in der 1. Spalte der Matrix Daten$ abgestellt. Damit stehen sie einzeln für beliebige Verarbeitungen zur Verfügung.

41000 REM subroutine: lesen des satzes an satz%+3 und abstellen in daten$(1,1) bis daten$(1,feldanzahl%)
41100 GET #4, satz% + 3: x$ = all$
41110  FOR ppr% = 1 TO feldanzahl%
41120  feld$ = RIGHT$(STR$(ppr%), LEN(STR$(ppr%)) - 1): feld$ = CHR$(255) + feld$ + CHR$(255): l1% = LEN(feld$)
41121  feldfollow$ = RIGHT$(STR$(ppr% + 1), LEN(STR$(ppr%)) - 1): feldfollow$ = CHR$(255) + feldfollow$ + CHR$(255):
41130  s1% = INSTR(x$, feld$): s2% = INSTR(x$, feldfollow$): IF s1% + l1% < s2% THEN daten$(1, ppr%) = MID$(x$, s1% + l1%, s2% - s1% - l1%) ELSE daten$(1, ppr%) = ""
41200 NEXT ppr%: RETURN

 

 

 

 

 

 

 

 

 

 

Auf heutigen Computersystemen erlaubt das verwendete BASIC bis zu mehr als 2 Milliarden Datensätze pro Datei:
Ein Blick mit dem Windows-Editor in eine Datei, die nach dem Prinzip erstellt wurde, sieht so aus:

 

 

In einem Test schrieb ich 1.000.000 (eine Millionen) Datensätze mit einer Länge von jeweils 1.024 Bytes /einem KB in eine zuvor nicht vorhandene Datei namens bluebird.htm. Es dauerte knapp mehr als 16 Sekunden, und die zehn Millionen Datensätze waren vollständig in den Cache geschrieben, aber noch nicht vollständig auf Platte gespeichert. Das Programm war schneller als die Festplatte, die brauchte noch etwa 1 bis 2 Sekunden länger, dann wurde die Datei bluebird.htm mit 1.000.000 KB im Ordner angezeigt, siehe die beiden folgenden Screenshots:

 

 

 

 

          

 

 

 

 

 

Schon Anfang der 90-ger Jahre setzte ich bei Fa. Großjohann, Oberhausen, eine einfache, aber superschnelle und sauber arbeitende Indexverwaltung ein, für die ich damals die Ramdisk unter MS-DOS als Datenverschiebebahnhof nutzte. Diese Indexverwaltung erlaubt es, unabhängig von der Länge eines Schlüsselbegriffs, die Sortiereihenfolge nur über die Verwaltung von Satznummern zu gestalten.

Für bis zu 32.767 Datensätze werden (numerisch gepackt) damit nur jeweils 2 Bytes im Index benötigt, für bis zu 9.999.999 Datensätze werden (numerisch gepackt) damit nur jeweils 4 Bytes im Index benötigt. Erst darüber (für bis zu mehr als 2 Milliarden Datensätze) werden 8 Bytes pro Key benötigt.

Hinzu kommt eine Verwaltung der freien Datensätze, die tatsächlich mit einem einzigen Byte (theoretisch: mit einem BIT!) pro Datensatz auskam und auskommt.

Geschwindigkeitstests haben ergeben, dass es heutzutage auch ohne getricksten Zusatz-Basicspeicher klappen muss, weil die Bearbeitung von Strings und deren Schreiben auf die Platte und deren Lesen von der Platte (bzw. in und aus dem Cache) heutzutage wesentlich schneller laufen als damals auf den alten Kisten unter MS-DOS.

1000 Datensätze mit jeweils 6 KB Länge zu manipulieren und zu schreiben, dauerte im Test rund 0,05 Sekunden. Kaum länger würde es entsprechend dauern, einen Indexbegriff in eine Indexdatei mit 9 Millionen Schlüsseln einzufügen oder aus ihr zu löschen.

Zu dem Test siehe die beiden Screenshots unten. Anmerkung: Die Tests liefen alle mit nicht compiliertem Basic einfach unter qbasic, es ist allerdings kaum anzunehmen, dass compiliertes Basic bei diesen Tests noch um zehnerpotenzen schneller wäre.