Hi,
Zitat von
hanspeter:
Die Datenbank handelt eine Veranstaltung und geht danach in die Ablage.
du hast Dir dabei sicherlich einiges überlegt das Design so zu machen, vielleicht war es auch der Wunsch des Anwenders - aber dieses Vorgehen führt meiner Meinung nur zu Problemen:
Ich denke doch, dass die Leute nicht direkt in der Datenbank rumeditieren, sondern dass Du eine Anwendung dazu hast. Was passiert, wenn Du diese mal änderst und die Anwendung eine andere Tabellenstruktur erwartet? Vielleicht kommen ja neue Tabellen dazu usw...
Ein "Reimport" über Backup-Restore scheidet daher meiner Meinung nach aus, da Du sonst die Datenbank nach dem Öffnen erst mal überprüfen musst und gegebenenfalls die Tabellenstruktur anpassen musst.
Ein Export in ein anderes Format wie
XML ist meiner Meinung nach aber auch unsinnig, denn dazu hast Du ja eigentlich die Firebird-
DB im Einsatz.
Was spricht dagegen in einer Datenbank mehrere Veranstaltungen zu speichern? Der Anwender muss davon ja nichts mitbekommen. Vor allem muss er nicht alle paar Monate die Datenbank runterfahren, das Datenbankfile wegkopieren und ein neues anlegen...
Sollte das aber aus welchen Gründen auch immer nicht gehen, dann sehe ich den Export in ein neutrales Format wie
XML als "beste unsinnige" Lösung an
Da kannst Du dann beim Importieren evtl. Änderungen im Datenmodell einfach handhaben. Für den Export in ein
XML sollte es eigentlich fertige Komponenten geben. Im schlimmsten Fall jede Tabelle einzeln in je ein
XMl auslesen und alle
XML in einen Zip-Container verfrachten.
Wenn Du dir das Leben dann noch vereinfachen willst, baust Du dir einen kleinen Viewer, der den Ihnalt der ausgelesenen
XML-Files anzeigen kann, dann müssen die Anwender die Daten nicht mehr importieren....
GRüße
Lemmy