Design Frage - Datenbanken inapp deployment und Updates

[fisipjm]

Hi,

ich hätte da mal eine Frage zum desgin einer Mobilen Anwendung. Also folgendes Vorhaben steht im Raum, ich möchte eine mobile Anwendung (hautpsächlich iOS, Android) schreiben, die Daten in einer lokalen SQLite Datenbank speichert. So weit so unspektakulär :D

Meine Frage ist jetzt die Folgende. Ich erstelle die App und die Datenbank, indem ich die Datenbank in das Projekt mit aufnehme, also die fertig generierte Datenbank bei Installation der App mit auf das Endgerät übertragen wird. Die Pfade sind natürlich relativ zum eingesetzten OS und das funktioniert auch alles wie gewollt.
Wie sieht das aus wenn ich im Laufe dieses Projekts neue Funktionen deployen will, Updates im Quellcode, die vielleicht auch mit Erweiterungen der Datenbank einhergehen. Wie setzt man das um? Ich gehe zum aktuellen Zeitpunkt davon aus, dass man sich damit die bestehede Datenbank wieder überschreibt, was milde gesagt suboptimal wäre :D
Wie geht man bei sowas vor, hat jemand Erfahrungen damit?

[Uwe Raabe]

Das ist doch bei Desktop-Anwendungen nicht anders, bis auf den Vorteil, bei mobilen Anwendungen in der Regel alleinige Schreibrechte auf der DB zu haben.

Ein recht verbreitetes Vorgehen ist, bei jedem Update die nötigen SQL-Skripte auszuführen um die DB vom bestehenden in den neuen Zustand zu überführen. Dazu speichert man die DB-Version am besten direkt in der Datenbank ab. Werden bei einem Update mehrere Versionen übersprungen laufen die Updates dann kaskadiert ab.

Es ist zu beachten, dass dieses DB-Update auch nach dem Einspielen einer Datensicherung nötig sein kann - nicht nur bei einem Programmupdate.

[fisipjm]

Hi Uwe,

soweit verständlich, aber ich schiebe ja aktuell die Datenbank mit rüber bei der Erstinstallation (Ich erzeuge sie nicht durch skripte). Wird die dann beim Update nicht überschrieben wenn Sie schon existiert?

Grüße
PJM

[Uwe Raabe]

Na ja, du musst schon sicherstellen, dass die bestehende DB bei einem Update eben nicht überschrieben wird. Du könntest das so lösen, dass du die DB unter einem anderen Namen anlegst, als der unter der sie bei der Installation erstellt wird (z.B: DBWork und DBOrg). Beim ersten Programmstart fehlt dann die DBWork und du kopierst die DBOrg als DBWork. Bei einem Update kommt dann zwar eine DBOrg wieder, aber ignorierst du erstmal.

Weiterer Vorteil: Du kannst eine Funktion anbieten, mit der du die DBOrg wieder zur DBWork kopierst - so als Reset DB to Default.

[joachimd]

Ich würde von Anfang an die DB im Code erzeugen, d.h. schlägt das Öffnen fehl, weil nicht vorhanden, wird die DB erzeugt und die notwendigen Tabellen angelegt, evtl Default-Daten eingefügt. Damit kannst Du zB die App auch komplett zurücksetzen - einfach die DB-Datei löschen.

[fisipjm]

Hmmm, also ich finde beide der vorgeschlagenen Varianten reizvoll. Wobei mir die von Uwe aktuell besser gefällt, einfach weil ich Faul bin :-D

Als Pro Argument für die Erzeugung würde ja sprechen, dass ich den Speicherplatz spare, wobei ich, wenn ich darauf achten würde kein Delphi verwenden würde *hust*

Sonst noch pro und contra Punkte die euch einfallen, ansonsten würde ich eher zur Variante von Uwe tendieren :)
Danke schon mal für die Antworten an einem Sonntag, hätte ich ehrlich gesagt gar nicht mit gerechnet.

[haentschman]

Moin...:P

Vieleicht solltest du erzählen wofür die Datenbank verwendet wird:

1. Vorgaben der Anwendung (statisch)
2. Datenbank mit "Userdaten": Quasi Daten, die der User oder die App selbst gespeichert hat.

Bei 1.:
Datenbank kann beim Update ausgetauscht werden.

Bei 2.:
Variante 1 nicht möglich!

Zitat:

Ein recht verbreitetes Vorgehen ist, bei jedem Update die nötigen SQL-Skripte auszuführen um die DB vom bestehenden in den neuen Zustand zu überführen. Dazu speichert man die DB-Version am besten direkt in der Datenbank ab. Werden bei einem Update mehrere Versionen übersprungen laufen die Updates dann kaskadiert ab.

...so macht man das. :thumb:

Wenn du nicht sicher stellen kannst, daß nie "Userdaten" in die Datenbank kommen...ausschließlich Variante 2. :zwinker:

Zitat:

die Daten in einer lokalen SQLite Datenbank speichert

...damit hast dir die Anwort selbst gegeben. :zwinker:

:wink:

[Rollo62]

Zitat:

Zitat von joachimd (Beitrag 1497526)

Ich würde von Anfang an die DB im Code erzeugen, ...

Jawoll, aber auch aus dem Grund weil die DB unter Umständen nicht binärkompatibel ist,
erzeugt auf Windows, gelesen aus Android.
Das kann Probleme geben (hatte sowas mal vor Jahren probiert, und bin dann auf Neuerstellung bei Android gegangen).
Sqlite ist eine DB, und kein Datenaustauschformat.

[fisipjm]

Zitat:

Zitat von haentschman (Beitrag 1497529)

Moin...:P

Bei 2.:
Variante 1 nicht möglich!

Zitat:

Ein recht verbreitetes Vorgehen ist, bei jedem Update die nötigen SQL-Skripte auszuführen um die DB vom bestehenden in den neuen Zustand zu überführen. Dazu speichert man die DB-Version am besten direkt in der Datenbank ab. Werden bei einem Update mehrere Versionen übersprungen laufen die Updates dann kaskadiert ab.

...so macht man das. :thumb:
:wink:

Es geht Definitiv um Userdaten. Die sollen und dürfen auch nicht verloren gehen. Zum aktuellen Zeitpunkt ist mir das Vorgehen mit der Versionsnummer und der erweiterung der DB druch die Scripte klar, danke soweit.

Die Frage die noch im Raum Stand war, von Anfang an mit Skripten arbeiten oder den Kopievorschlag von Uwe nehmen. Oder ist das reine geschmackssache und macht dann keinen größeren Unterschied mehr?

[haentschman]

Moin...8-)

Zitat:

von Anfang an mit Skripten arbeiten

...ja. :zwinker:

Zitat:

Die sollen und dürfen auch nicht verloren gehen

...wie soll das bei einer Kopie gehen? Du müßtest dann die Daten trennen und wieder zurückspielen. Wenn die noch in den gleichen Tabellen stehen...viel Spaß! :roll: