Wie ermitteln, ob Datenbankstruktur aktuell ist?

  • Allgemein

Es gibt 6 Antworten in diesem Thema. Der letzte Beitrag () ist von GambaJo.

    Wie ermitteln, ob Datenbankstruktur aktuell ist?

    Angenommen ich habe eine fertige Datenbank-Applikation (in meinem Falle SQLite als DB). Und weiterhin angenommen ich möchte nun weitere Funktionen und damit weitere Spalten, Tabellen, Schlüssel usw. einfügen.

    Wenn die Anwendung schon bei Usern installiert ist, muss beim Installieren (oder spätestens beim ersten Starten) der neuen Version die Struktur der vorhandenen Datenbank mit aktualisiert werden, damit sie zur Anwendung passt.

    Das Aktualisieren der Struktur an sich ist kein Problem. Aber wie bekomme ich heraus, dass ich ak-tualisieren muss? Die Aktualisierung soll ja nur ein Mal pro Version laufen. Außerdem muss man auch solche Fälle beachten, in denen der User nicht linear (Ver. 1, dann Ver.2, dann Ver.3, usw.) seine Software updated, sondern dass er auch mal einige Versionen überspringen könnte (Ver.1, dann Ver.4). Auch dann müssen ja alle Aktualisierungen aller Versionen laufen, und nicht nur die der letzten Version.

    Ich habe mir überlegt, dass man eine Tabelle (1 Tabelle, 1 Spalte, 1 Datensatz) anlegt, in der die Version der Struktur der Datenbank steht. Wenn die Version der Software höher ist, weiß die Software, dass die Struktur aktualisiert werden muss.
    Das erscheint mir aber zum einen etwas unsicher, und zum anderen auch mit Kanonen auf Spatzen geschossen.
    Hat die Datenbank nicht vielleicht eine Eigenschaft genau für diesen Zweck, die man per Code setzen kann, und die auch persistent ist?

    Oder wie geht ihr in einem solchen Fall vor?
    Das wäre auch eine Möglichkeit. Finde ich allerdings etwas unperformant, da bei jedem Start unter Umständen auf ziemlich viele Elemente per SQL geprüft werden müsste. Das könnte den Start unnötig in die Länge ziehen.

    EDIT:

    Ich habe auf vielen Android-Seiten eine GetVersion() und eine SetVersion()-Methode gefunden, mit der genau mein Fall abgedeckt wird.
    Werde morgen mal schauen, ob es das auch in .net gibt.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „GambaJo“ ()

    @ GambaJo

    Der ganz klassische und sinnvollste Weg, wäre das Du im Backend eine Info-Tabelle anlegst. BE-Versions-Nummer, Datum etc. .

    Somit ist es dann mehr als easy auszulesen welchen Stand das backend hat und welche Updates nötig sind um das Backend auf den aktuell gültigen Stand, bzw. den für das Frontend vorausgesetzten Stand zu updaten.

    Musst halt nach jedem Backend-Update die Information zu BE-Versions-Nummer mit updaten, aber das ist ja wohl nicht das Thema. ;)

    Brauchst dann halt nur eine Funktion die das Info-Table beim Start aus dem Backend ausliest und abgleich welches Update für diese Backend-Version zu fahren ist und wenn ein Update zu fahren ist, dann am Ende einen erneuten Aufruf um zu prüfen ob noch ein weiteres Update nötig ist usw., usw. ... bis die Version erreicht ist für die kein Update mehr nötig ist.

    EDIT:


    Ich habe auf vielen Android-Seiten eine GetVersion() und eine SetVersion()-Methode gefunden, mit der genau mein Fall abgedeckt wird.
    Werde morgen mal schauen, ob es das auch in .net gibt


    Meines Wissens nach nicht, gehört zumindest nicht zum standardmäßigen Funktionsumfang den SQLite bietet, wenn müssen es also Objekt-spezifische Methoden sein. Wäre dann nur spannend zu wissen wohin die die Daten speichern/woher auslesen da die standardmäßig ja nicht im Master_Table vorhanden sind und SQLite eben nicht Server basiert ist. Vielleicht handelt es sich dabei um die Dateiinformationen des SQLite-DB-Files an sich?

    Gruß

    Rainer

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „raist10“ ()

    @raist10: Genau das habe ich ja in meinem ersten Posting vorgeschlagen.
    Ich finde nur, dass es zu viel Aufwand ist extra dafür eine Tabelle zu führen. Und unsicher ist es auch, da man diese Nummer relativ einfach manipulieren und somit Murks fabrizieren könnte.

    Wenn alle Stricke reißen, und ich keine bessere Lösung finde, werde ich das wohl so machen müssen.

    GambaJo schrieb:

    @raist10: Genau das habe ich ja in meinem ersten Posting vorgeschlagen.
    Ich finde nur, dass es zu viel Aufwand ist extra dafür eine Tabelle zu führen. Und unsicher ist es auch, da man diese Nummer relativ einfach manipulieren und somit Murks fabrizieren könnte.

    Wenn alle Stricke reißen, und ich keine bessere Lösung finde, werde ich das wohl so machen müssen.


    Ja, und ich wollte Dich bestätigen das das die richtige Lösung ist, weil es immer so gemacht wird (zumindest bei Single-File-DB's). ^^

    Gruß

    Rainer