Eigene Datenbank nicht performant?



  • Hallo Forum,

    vielleicht ist es auch ein generelles C/C++-Problem, aber in diesem Fall können die Admins sie ja verschieben; ich dachte nur, hier hätte ich mehr Zulauf.

    Zur Sache: Ich bin gerade dabei eine kleine Anwendung zu schreiben (MFC SDI, falls es jemanden interessiert). Da ich eine Datenbank benötige (OO) und noch auf kein open source Paket gestossen bin, wollte ich auch die Datenhaltung selbst implementieren.

    Dazu habe ich folgende Überlegungen angestellt: Ich habe eine Klasse, nennen wir sie CDatabase, die eine verkettete Liste darstellt und verschiedene Objekte darin speichert - alle vom Typ CDatabaseObject bzw. davon abgeleiteten Klassen.

    Wenn diese Objekte nun miteinander agieren sollen (Daten austauschen), so regelt sich das mit Zeigern recht schnell. So könnte jedes Objekt einige Zeiger besitzen, über die man dann auf die anderen Objekte verweist. Nun das Problem dabei: Die Datenbankfunktionalität ist zur Laufzeit vorhanden, keine Frage. Wie mache ich die Daten aber persistent?

    Schreibe ich die Objekte und lese sie wieder ein mit allen Variablen, so ist die Konsistenz natürlich dahin (die Zeiger zeigen ins Nichts...). Nun hab ich mir folgendes überlegt:

    Jede Objekt-Klasse besitzt für jeden ihrer Zeiger auch eine Variable mit gleichem Namen. Da ich für jedes Objekt auch eine eindeutige Objekt-ID vergeben habe, lege ich in die zweite Variable neben dem Zeiger die ID des Objekts, auf das der Zeiger verzweigt. So kann ich problemlos die Daten auch wieder einlesen.

    Und jetzt der Knackpunkt: Bevor ich über die Werte in den Variablen mit den ObjektIDs die Zeiger wieder herstellen kann, müssen zunächst einmal ALLE Objekte im Speicher stehen, bevor ich sie verbinden kann. Also muss ich 1) zuerst alle Objekte einlesen und 2) danach die Zeiger eines jeden Objekts aktualisieren. Und da die Objekte in einer verketteten Liste liegen, muss ich sequentiell fast alle Objekte durchgehen (bzw. deren Zeiger), bis das richtige gefunden ist.

    Das ist ja eigentlich noch kein Problem... 😉 Wenn ich nämlich ein Objekt aus der Liste löschen will, geht der Spass erst los: Ich müsste theoretisch ALLE Zeiger von JEDEM Objekt (OHNE Ausnahme) nach dem zu löschenden Zeiger durchsuchen, damit nicht aus Versehen ein Objekt gelöscht wird, auf das einige Zeiger noch zeigen - unvorhersehbare Speicherüberläufe gebe ich dann gern schriftlich!

    Ich hoffe, jemand versteht mein Problem: Man muss ALLE Zeiger überprüfen (sequentiell), um die Kosistenz zu gewährleisten. Bei etwa 100 Objekten: Kein Problem, jeder moderne Rechner braucht keine Sekunde. Was aber bei 100000 Objekten? Oder mehr? Der Rechenaufwand steigt nicht linear, deswegen: Hat vielleicht jemand eine Idee, wie man feststellen kann, ob sich sowas noch performant verhält? Wenn jemand wirklich interessiert ist, lasse ich ihm gerne den Code zur Einsicht zukommen.

    Auf Hilfe hoffend... 😃



  • MYSQL für Windows ist OpenSource und in der Theorie frei.



  • such mal nach POST++



  • @Unix-Tom

    mysql? Ist das nicht eine "relationale" Datenbank?

    Ich werde erst einmal nach POST++ suchen, ansonsten melde ich mich wieder hier...

    Danke trotzdem!



  • benutze smartpointer (oder waren das autopointer?) jedenfalls löschen sich da objeckte selbst, wenn also in deiner datenbank liste ein objeckt gelöscht werden soll, nimmst du es aus der liste und lässt es im ram gammeln, wenn da nichts mehr drauf zeigt, wird delete this; ausgeführt, ansonsten bleibt das objeckt am leben.

    jetzt mußt du das objeckt natürlich erst immer fragen, ob es noch in der hauptliste ist, bevor du es benutzt, ansonsten machst du denn autopointer=NULL;... irgendwann zeigt kein objeckt mehr auf die nicht in der liste existierenden objeckte und sie sind weg...

    rapso->greets();

    (also das mit den autopointern meine ich so:

    jeder pointer der auf ein objeckt zeigt erhöcht dort mit einer function den referenzcounter, jeder pointer der von einem objeckt ablässt decreast den referenzcounter mit einer function des objecktes; beim decrease muss das objeckt nachsehen, ob der referenzcounter==0 ist, dann löscht es sich nämlich selbst, weil niemand mehr drauf zeigt und es ein memory leak darstellt 🙂
    )

    hoffe alles verständlich, ansonsten melde dich...



  • Original erstellt von volkard:
    such mal nach POST++

    Nur so nebenbei: JUCHU!!! Meine Firma ist enthalten!! POST!! *lol* 😃 😃 😃

    *nichts für ungut, sorry*


Anmelden zum Antworten