OODB - Das eigenständige OOBD Datenbank Format

Es gibt einige Gründe / Vorteile für das Aufsetzen eines eigenständigen Formates für die OOBD Datenbank:

• der Hauptgrund ist: Es gibt kein reales Bedürfnis eine Super-Duper Abfragemaschine wie “WÄHLE das, jenes VON da, dort WO alles=nichts ist..”, eine einfache Schlüssel → Wert(e) Ablesestabelle ist das was wir täglich am meisten brauchen
• geringe Speichernutzung: die gesamte Suche ist Datenfile basiert, Speicher wird nur zeitweise für gefundene Daten benutzt
• generische Eingabeströme: Die Datenbank benötigt nur einen Eingabestrom als Quelle, welche ausschließlich in Vorwärtsrichtung gelesen wird. Durch Dieses können z.B. verschluesselte Daten benutzt werden.
• Hohe Geschwindigkeit: Die ganze Suche ist nur ein ausgewogener Binärbaumabgleich, welcher es schnell macht, auch auf langsamen Prozessoren

Solche OOBD Datenabkfiles werden erzeugt, wenn man ein CSV (über Kommata separierte Werte) Eingabefile benutzt, in dem in Wirklichkeit die Werte nicht durch Kommatas getrennt sind, sondern durch Tabs.

Solch ein Eingabefile, welches die unten angegebenen Anforderungen erfüllen muss, wird übersetzt durch das oodbCreateCli php Skript:

 oodbCreateCli eingabefile.csv > ausgabefile.oobd

Das ausgabefile.oobd gehört dann in das gleiche Verzeichnis wie das Lua Skript, welches die Datenbank benutzen möchte.

Das Datenformat des Eingabefiles muss folgendermaßen aussehen:

HeaderLine \n
Line 1 \n
…
Line n \n

where

HeaderLine =
(colum_name 0)
[\t (colum_name 1)]
…
[\t (colum_name n)]

Line =
Key \t Values

Values =
(Value_of_Colum 0)
[\t (Value_of_Colum 1)]
…
[\t (Value_of_Colum n)]

Das Eingabefile muss aufsteigend nach den Schlüsseln sortiert sein.

Falls es mehr als einen Wert pro Schlüssel gibt, müssen die Werte in der Reihenfolge sortiert sein, wie sie später in der Suche auftauchen werden.

Zeilen die mit dem # Zeichen beginnen, werden als Kommentarzeilen betrachtet und in der Bearbeitung unterdrückt.

Das erzeugte Ausgabedatenformat wird wie folgt aussehen:

HeaderLine 0x0
Entry 1
..
Entry n

Entry =
Key 0x0
Offset (for key > Searchstring)
Offset (for key < Searchstring)
Value 1 0x0
[..Values n 0x0]
0x0

Offset =

binary unsigned 32-Bit Big Endian, calculated as skip() value from the fileposition after the second 4-Byte value up to the start of the next key string to be evaluated. To distingluish between an offset of 0 to the next key string and a 0 as the indicator for the end of the search tree, the skip() offset given in the file is always 1 higher as in reality, so 1 needs to be subtracted to have the correct jump width (e.g. Offset in file: 9 means real jump width 9 -1 = 8 = skip(8)

How to read this file:

1 - Read Headerline (from the file beginning until the first 0x0). Store this data for later naming of the found columns.
2 - read key value (0x0- terminated String) and the both next 4 Byte long skip() offsets (= relative file positions) for the greater and smaller key value. If they are 0 (zero), there's no more smaller or greater key available
3 - compare key with search string:
    - if equal, read attached values in an array. This array then contains the search result(s). Return this and the header line as positive search result.
    - if smaller:
          if smaller file position is 0 (zero), then return from search with empty result array.
          if smaller file position is not 0, jump per skip( value - 1 ) to the file postion of the next index string and continue again with step 2
    - if bigger:
          if bigger file position is 0 (zero), then return from search with empty result array.
          if bigger file position is not 0, jump per skip(value - 1 ) to the file postion of the next index string and continue again with step 2