Design Frage - Datenbanken inapp deployment und Updates

[fisipjm]

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

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...

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.

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

Zitat:

die Daten in einer lokalen SQLite Datenbank speichert

...damit hast dir die Anwort selbst gegeben.

[fisipjm]

Zitat von haentschman:

Moin...

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.

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...

Zitat:

von Anfang an mit Skripten arbeiten

...ja.

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ß!

[fisipjm]

Zitat von haentschman:

Moin..

Zitat:

von Anfang an mit Skripten arbeiten

...ja.

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ß!

Moin,
ich glaub die Idee wurde nicht ganz deutlich. Es geht einzig und allein nur um die erstmalige Erstellung bzw. den Reset der Datenbank. Man liefert also eine "Origignal.sdb" mit aus und wenn eine "Work.sdb" nicht vorhanden ist kopiert man die "Original.sdb" mit dem Namen "Work.sdb" in das gleiche Verzeichnis. Die Updates laufen natürlich über Updateskripte anders kanns ja nicht gehen. Es geht lediglich darum ob es Vor/Nachteile gibt bei der erstmaligen Anlage durch Kopie oder Skript.

[haentschman]

Moin...

Zitat:

bei der erstmaligen Anlage durch Kopie oder Skript

Beim erstmaligen Anlegen würde ich auch die komplette DB installieren. Danach nur über Scripte...