Nanu, hier gabs ja inzwischen neue Beiträge
Wieso wurde ich darüebr nciht benachrichtigt?
Ich habe nicht vor, die gesamte Datenbank im Programmspeicher zu halten, das wäre ja absolut kontraproduktiv. Daher helfen mir hier auch Hashmaps nicht.
Eigentlich wollte ich jetzt aber mal über den aktuellen Stand schreiben. Ich bin schon bei der Implementierung, aber ich bin mir unsicher, ob ich nicht vielleicht gerade das
Rad neu erfinde, und Klassen schreibe, die es schon standardmäßig gibt - denn wie gesagt hab ich unter Delphi noch nix mit Datenbaken zu tun gehabt.
Hier ist das Konzept:
Es gibt folgende (wichtige) Klassen:
- Datenbank (TDatabase)
- Tabelle (TTable)
- Datensatz/Zeile in einer Tabelle (TTableRow)
- Feld (TField)
- Feld-Wert (TFieldValue)
- Resultat einer Abfrage (Liste) (TQueryResult)
- Datensatz/Zeile in einer Abfrage (TQueryResultRow)
Es gibt also die Basislasse TTableRow für einen Datensatz in einer Tabelle, quasi eine Zeile. Die Felder eines Datensatzes (TField) werden in einer Liste von TTableRow verwaltet. Die Werte dieser Felder (TFieldValue) sind selbst Objekte eines abstrakten Typs. Einer der Vorteile: Die Klasse TTableRow ist selbst von TFieldValue abgeleitet, d.h. mit Referenzen kann hier sehr elegant umgegangen werden. Zur Identifizierung kann jede Zeile eine eindeutige ID zugewiesen bekommen, das ist zwar nicht zwingend, aber bestimmte Funktionen lassen sich sonst eben nicht nutzen.
Die Datenbank wird eine Funktion haben, einen
Query auszuführen. Das Ergebnis wird als TQueryResult ausgegeben. Statt die Felder direkt zu beinhalten, beinhaltet TQueryResult Referenzen auf die entsprechenden Tabellendatensätze, die die angeforderten Informationen enthalten. Das soll die Verwaltung vereinfachen und dafür sorgen, dass die Datenbankstruktur besser auf die Klassenstruktur übertragen wird.
Natürlich kann und wird es passieren, dass die gleichen Tabellendatensätze an verschiedenen Stellen verwendet werden. Damit die Daten synchron bleiben, speichert jede TTableRow Referenzen auf andere TTableRow-Objekte, die auf den gleichen Datensatz zugreifen. Hier kommt die Klasse TTable ins Spiel, die eine Liste mit Datensätzen entählt, die im Progamm in Verwendung sind. Dazu kennt jedes TTableRow-Objekt die Tabelle, zu der es gehört. Wenn nun ein neues TTableRow-Objekt durch eine Abfrage angelegt wird, prüft es zunächst ob in seiner Tabelle dieser Datensatz schon vorhanden ist (dazu nutzt es die optionale ID), wenn nein, fügt es sich zur Referenzliste der Tabelle hinzu, sonst pickt es sich das dort vorhandene Objekt (ich nenn es jetzt mal den Verwalter) heraus, und meldet sich dort an. Es wird dann zur Referenzliste dieses Verwalters, sowie aller Referenzen, die der Verwalter kennt, hinzugefügt. Ebenso kopiert es alle "Bekannten" dieses Verwalters, sowie den Verwalter, in seine eigene Referenzliste ein. Wird ein Objekt zerstört, entfernt es sich automatisch aus den Referenzlisten der anderen Objekte. Falls das Objekt der Verwalter ist, wird das erste Objekt in seiner Referenzliste sein Nachfolger. Falls kein Nachfolger vorhanden ist, wird das Objekt aus der Referenzliste der Tabelle entfernt.
Statt der ganzen Listen hatte ich auch schon über Interfaces nachgedacht (Referenzzähler), aber da ich von Interfaces keine Ahnung habe, möchte ich lieber die Finger davon lassen, statt mir eine weitere Fehlerquelle ins Programm zu holen
Es ist so gedacht, dass die oben genannten Klassen nicht direkt verwenden werden, sondern nur das Grundgerüst darstellen. Letztendlich sollen abgeleitete Klassen verwendet werden, die die Datenstruktur repräsentieren. Für jede Tabelle wird eine eigene Klasse von TTable abgeleitet etc. Das könnte von einem Generator automatisch erledigt werden.
Ich hoffe mein Ansatz ist deutlich geworden. Nun möchte ich gerne hören, was ihr davon haltet. Zu komplex?
Rad neu erfunden? Oder vielleicht total genial?
Vielen Dank schonmal fürs Lesen und eure Antworten!