PureBoard

So, es gibt wieder ein Update.

+Added: PokeDB() schreibt die Datenbank in einen Speicherbereich
+Added: PeekDB() liest die Datenbank aus einem Speicherbereich
+Added: Size() gibt die Größe der DB, die zum Speichern benötigt wird, an
+Fixed: WriteDB() (somit auch SaveDB()) schreibt jetzt ein etwas anderes Format, womit die Dateigröße pro Zeile auch noch um 4 Byte schrumpft
+Changed: ReadDB() (somit auch LoadDB()) auf WriteDB() angepasst
+Added: Eine Fehlermeldung kam durch PeekDB() und PokeDB() hinzu
+Fixed: Ein paar interne Änderungen, die zu Fehler hätten führen können

Ansonsten bin ich wirklich schwer am Grübeln wie ich das jetzt mit dem
Spalten löschen machen soll, damit der Platz, der beim Löschen entsteht,
beim Anfügen einer neuen Spalte auch anständig genutzt wird.

Naja, wie gesagt: Ich bin dran!

Diesmal kann ich sogar den Code wieder hochladen Dank www2ftp.

Hai Nic,

kannst Du Dir noch mal die Procedure.s DB_PeekM(*pBuffer.Long)
anschauen? Ich denke, dass der Rückgabewert Long sein sollte und nicht
String

Grüße ... Kiffi

Ja... stimmt... komisch...

Funktioniert jetzt!


Mal was anderes: Soll ich den Thread-Titel jetzt schon "Große Dynamische
Datenbank im Interface-Stil" nennen oder soll ich es so lassen wie es ist?

> Funktioniert jetzt!

sehr gut! Danke! Momentan machste Deinem Namen wieder alle Ehre.

> Mal was anderes: Soll ich den Thread-Titel jetzt schon "Große Dynamische
> Datenbank im Interface-Stil" nennen oder soll ich es so lassen wie es ist?

der jetzige Threadtitel versprüht einen gewissen Charme. Aus diesem Grund
würde ich ihn so lassen, wie er momentan ist.

Ähm, ShowDB() befindet sich in der Beispiele.pb? Die ist leider nicht mehr
vorhanden. Und ich habe sie 'damals' nur zuhause heruntergeladen. Kannst
Du sie noch einmal hochladen? Danke!

Grüße ... Kiffi

// Edit: Hat sich erledigt! Hab's wiedergefunden.

// Edit2:

so, ich habe jetzt ein wenig mit Deiner Datenbank herumgespielt und
folgendes Szenario ist enstanden: Ich ermittel alle Dateien in einem relativ
grossen Ordner (nebst Unterordnern). Dieses Dateien trage ich in die
Datenbank ein, sofern sie noch nicht vorhanden sind.
Hieraus ergibt sich nun folgendes Problem. Die ersten Daten werden in
einer relativ kurzen Zeit in die Datenbank eingetragen. Je mehr Daten
eingetragen werden, desto länger dauert der Vorgang. Der Grund ist in
der Abfrage SelectRowByEntryS() zu finden. Die Anzahl der zu
durchsuchenden Datensätze steigt mit der Anzahl der eingetragenen
Daten.

Ich denke, dass der Zeitpunkt geeignet ist, sich über die Indizierung der
Datenbankfelder Gedanken zu machen. Hier wird in der Datenbank ein
separater Speicherblock dafür genutzt, die Suchabfragen zu
beschleunigen. In diesem Speicherblock werden die Daten beispielsweise
alphabetisch in Untermengen aufgeteilt, so dass (in dem oben gezeigten
Beispiel) nicht mehr die gesamte Liste durchsucht werden muss, wenn nur
die erste Übereinstimmung nicht mehr zutrifft.

Weiterführende Infos biete Wikipedia:

http://de.wikipedia.org/wiki/Datenbankindex
http://de.wikipedia.org/wiki/Indexstruktur

Ich denke, dass das keine besondere Herausforderung für Dich ist

Grüße ... Kiffi

Ich werde mal schauen, ob sich da morgen was ergibt.

Danke für die Links!

Alles klar, ich hab mich jetzt zumindest mal entschieden. Ich denke, ich
nehme den B-Baum. Der ist am einfachsten und scheint mir auch am
effektivsten.

Ich werde die Indizierung zunächst nur für String-Spalten machen. Und
wegen dem Schlüsselgenerator werde ich mal ein paar verschiedene Sachen
ausprobieren.

Ich mache dafür ein eigenes Interface, das ich dann in mein DB-Interface
einpflegen werde. Ich hab auch schon eine Idee, wie ich alles unabhängig
von Groß- und Kleinschreibung machen könnte.

Na dann macht euch mal auf was gefasst. Ich bin mal zuversichtlich.

///Edit:
Ich hab das System noch etwas abgeändert, sodass ich es noch etwas
besser finde als es normal gedacht ist. Na mal abwarten, was daraus wird. Kann sich nur noch um Jahre handlen.

Ich habe gerade bemerkt, dass meine Datenbank für eine Hashfunktion
noch nicht vorbereitet ist. Dazu muss ich intern noch einiges ändern, was
fast in jeder Funktion drin ist. Und zwar brauche ich gleichzeitig ein Array
und eine LinkedList, damit es schnell genug bleibt.

Ich werde das Problem mal kurz erläutern:
Die kommende Hashfunktion soll Strings oder Zahlen durch einen
Hash-Generator schicken und mit dem Hash dann eine Tabelle anlegen, in
der jedem Hash eine eindeutige ID zu einem Eintrag in der eigentlichen
Datenbank zugewiesen wird.

Jetzt unterstützt aber meine Datenbank noch nicht die Rückgabe einer
eindeutigen ID. Bisher kann man Zeilen nur per Index ansprechen, der
sich aber bei allen Zeilen aber ändert, wenn man z.B. vor der ersten Zeile
noch eine Zeile einfügt. Logisch. Also kann ich diesen Index schonmal
nicht als eindutige ID in die Hashtabelle einbauen.

Aber jede Zeile hat ihren eigenen Pointer, den ich verwenden könnte. Aber
um eine Zeile mit dem Pointer zur aktuellen zu machen, muss ich wieder
alle Zeilen durchsuchen bis ich den Pointer gefunden habe. Also brauche
ich in der Datenbankstruktur nicht nur eine Variable, die festhält, welchen
Index die gerade aktuelle Zeile hat, sondern auch noch eine Variable, die
den Pointer der aktuellen Zeile behält.
Jetzt werde ich es so machen, dass jede Zeile zusätzlich noch die Pointer
der Vorgänger- und Nachfolgerzeile und außerdem ihren eigenen Index
besitzt. Der Index wird ignoriert, wenn vorher irgendwo eine Zeile
eingefügt wurde, weil er dann ja nicht mehr gültig ist. Wird der Index dann
aber irgendwann wieder gebraucht, wird er kurz neu erstellt und ist
dadurch wieder benutzbar.

Naja, so genau kann ich es gar nicht erklären, weil eigentlich noch ein
bisschen mehr dahinter steckt. Tatsache ist, dass das ganze Problem mit
der Hashfunktion noch größer ist als angenommen, aber ich der Lösung
auf der Spur bin.


Ich bin außerdem noch am Schwanken, ob ich eine statische Hashtabelle
oder eine dynamische benutze. Die statische ist wohl die schnellste,
beansprucht aber von Anfang an direkt viel Speicherplatz, der immer
weiter zunimmt, je mehr Einträge es gibt, während die Größe der
dynamischen Hashtabelle fast proportional zu der Anzahl der Einträge
wächst und einen geringen Teil langsamer ist.


Wie auch immer. Ich habe wieder genug geschwafelt und muss mal wieder
als Zivi etwas tätig werden und Zeitung lesen. Danach noch ein paar
Pressemitteilungen online stellen und Kaffe trinken. Dann fange ich mal an
mit dem Umbau der Datenbank.

PS.: Wer wissen will, wo ich Zivi mache: Universitätsklinikum des Saarlandes

So, die Datenbank ist soweit abgeändert. Und es war eine echt nervige
Arbeit, kann ich euch sagen...

Ich teste noch ein bisschen rum, da es anscheinend noch ein paar Bugs gibt,
die man sowieso immer erst später findet, aber naja...

Sobald ich mit testen fertig bin, lasse ich euch wieder testen und dann geht
es an die eigentliche Hashroutine.


Was mich auch etwas nervt: Erst jetzt ist mir aufgefallen wie schlecht ich
meine Datenbank "konstruiert" habe. Schlauer wäre es gewesen, wenn ich es
direkt so gemacht hätte wie auch die (neuen) LinkedLists von PB funktionen.
(Ich vermute zumindest mal, dass sie so funktionieren wie ich mir das gerade
vorstelle.)

Denn jetzt ist es so, dass immer ein zusammenhängender Speicherblock
existiert, der die Größe von Anzahl_der_Zeilen * 4 Bytes hat. Das sind
zwar bei 1048576 Zeilen erst 4 MB, aber trotzdem. Wenn ich jetzt
zwischendrin etwas einfüge, müssen immer alle anderen Einträge nach
hinten verschoben werden. Nach dem System, was ich jetzt im Kopf habe,
müsste nie etwas verschoben werden und kann trotzdem schnell durch
einen Index angesprochen werden. Die Datenbank funktionert dann so
ähnlich wie ein B-Baum bei den Hashalgorythmen.


Aber ich erzähle wieder viel zu viel. Morgen könnt ihr bestimmt wieder
testen.

(Ups, es ist ja schon morgen... )

Problem, das mir auch schon aufgefallen ist: http://www2ftp.de/ ist deaktiviert, weil irgendwelche Heinis da Phishing-Seiten hochgeladen haben.



Ist total blöd.

@Alves:
Echt blöd. Kennst du noch eine ähnliche Seite?

@all:
Es gibt ein Update! Siehe erster Post unter Edit 12. (wieviel es davon wohl
noch geben wird?)

///Edit:
Achso: Es gibt wieder ein Beispiel dazu wegen den Pointern.