Vorgehen beim Verändern einer Datenbank

[Freischreiber]

Hallo!

Was mir beim Arbeiten an meiner Datenbank immer Streß verursacht, ist folgendes Problem:

Änderungen macht man ja sinnvollerweise nicht an der Originaldatenbank, sondern an einer Kopie. Nur was ist, wenn während der Änderungen an der Originaldatenbank Datensätze dazukommen?

Am Ende habe ich eine wunderschöne erweiterte Datenbank (neue Tabellenspalten, neue Formulare, geänderte Formulare), aber die neue und die Original-DB passen nicht zusammen, weil die originale alle Datensätze enthält, aber die geänderte nicht.

Mir fällt dann immer nur ein, die Änderungen von der Kopie an der Original-DB nochmal nachzuvollziehen, was aufwendig und fehlerträchtig ist.

Rüberkopieren der originalen script-Datei in die neue DB geht nicht, weil so würden ja alle Änderungen an der DB (außer der neuen Formulare) wieder überschrieben. Umgekehrt selbes Problem.

Größere Pause an der Original-DB sind schwierig.

Wie macht ihr das?

Gruß
Freischreiber

[Pit Zyclade]

Dein Synonym sagt es ja schon: Du bist Vielschreiber! Das sind die wenigsten hier im Forum.
Darum habe sie dein Problem nicht.

Ich z.B. mache die Kopie, dann möglichst unmittelbar die (geringe) Änderung, dann Prüfung, dann Sicherung als neues Original usw.
Sollte entweder die Zeit oder Reihenfolge unterbrochen worden sein, dann wird von vorne begonnen, aber die erneute Kopie zum Ändern mit neuer Nummer versorgt, um bei der älteren Kopie die begonnenen Änderungen noch nachsehen zu können (mein Gedächtnis läßt mit dem Alter auch nach, wie bei allen).

[RobertG]

In Datenbanken, die ich für den produktiven Bereich erstelle, läuft ein Makro mit. Das Makro erstellt bei jeder neuen Öffnung der Base-Datei eine Sicherheitskopie ins Backup-Verzeichnis von LibreOffice. So habe ich nach kurzer Zeit ziemlich viele Backup-Dateien, die ich dadurch begrenze, dass ich nach 10 Backups immer die älteste Datei raus schmeiße. Das mache ich übrigens auch mit externen Firebird-Datenbankdateien so.

Wenn also eine Änderung nicht den gewünschten Erfolg hat gehe ich zurück auf das Vorgängermodell.

Allerdings: Ich gehe nur selten an die Datenstruktur, d.h. die Tabellen und ihre Verknüpfungen. Das gehört für mich zur Planung die Struktur so auf zu bauen, dass ich da nicht anschließend noch etwas ändern muss. Einfach Felder an eine Tabelle anhängen ist davon ja nicht betroffen. Muss ich zur Zeit z.B. bei alten DBs teilweise machen, um sie reif für die Erstellung von XRechnungen zu bekommen.

[Freischreiber]

...
Ich z.B. mache die Kopie, dann möglichst unmittelbar die (geringe) Änderung, dann Prüfung, dann Sicherung als neues Original usw.
Sollte entweder die Zeit oder Reihenfolge unterbrochen worden sein, dann wird von vorne begonnen, aber die erneute Kopie zum Ändern mit neuer Nummer versorgt, um bei der älteren Kopie die begonnenen Änderungen noch nachsehen zu können (mein Gedächtnis läßt mit dem Alter auch nach, wie bei allen).

Also Änderungen an der laufenden DB. Änderungen nachsehen ist immer schwierig, Änderungen an Abfragen oder Tabellen erkennt man erst, wenn man reingeht, und weiß, wo man suchen muß.

...
Wenn also eine Änderung nicht den gewünschten Erfolg hat gehe ich zurück auf das Vorgängermodell.

Allerdings: Ich gehe nur selten an die Datenstruktur, d.h. die Tabellen und ihre Verknüpfungen. Das gehört für mich zur Planung die Struktur so auf zu bauen, dass ich da nicht anschließend noch etwas ändern muss. Einfach Felder an eine Tabelle anhängen ist davon ja nicht betroffen. Muss ich zur Zeit z.B. bei alten DBs teilweise machen, um sie reif für die Erstellung von XRechnungen zu bekommen.

Dann dürfen aber seit dem Vorgängermodell keine Daten dazugekommen sein. Das ist ja mein Problem.

Den Königsweg gibt es wohl nicht.
Vermutlich empfiehlt es sich, einen Zeitraum festlegen, in dem keine Änderungen angenommen werden. Neue Daten landen dann eben vorübergehend in einer Textdatei, die später eingepflegt wird.

[Pit Zyclade]

... Neue Daten landen dann eben vorübergehend in einer Textdatei, die später eingepflegt wird.

Warum dass denn? Da lohnt sich doch eine Kopie, in der keine Daten drin von Datum x bis Datum y drin sind sind. Und die holt man dann später rüber. So stimmt dann wenigstens gleich die Struktur der Daten.

[Freischreiber]

... Neue Daten landen dann eben vorübergehend in einer Textdatei, die später eingepflegt wird.

Warum dass denn? Da lohnt sich doch eine Kopie, in der keine Daten drin von Datum x bis Datum y drin sind sind. Und die holt man dann später rüber. So stimmt dann wenigstens gleich die Struktur der Daten.

Wie, die holt man später rüber? Einfach Copy&Paste der Tabellenzeilen?

[Pit Zyclade]

... Neue Daten landen dann eben vorübergehend in einer Textdatei, die später eingepflegt wird.

Warum dass denn? Da lohnt sich doch eine Kopie, in der keine Daten drin von Datum x bis Datum y drin sind sind. Und die holt man dann später rüber. So stimmt dann wenigstens gleich die Struktur der Daten.

Wie, die holt man später rüber? Einfach Copy&Paste der Tabellenzeilen?

Das meinst du nicht ernsthaft oder? Wir sprechen von einer Datenbankkopie oder? Da kannst du doch alle Datensätze löschen und dort dann die neuen einfügen... bis du mit der Änderung der originären endgültig fertig bist. Und erst dann ergibt sich das Problem, ob du die neuen Datensätze einfach oder auf Umwegen rüberholen kannst. Jedenfalls verstand ich dein Problem so, dass du während der DB-Struktur-Änderung neue Datensätze nicht eingeben konntest...

[Freischreiber]

...
Und erst dann ergibt sich das Problem, ob du die neuen Datensätze einfach oder auf Umwegen rüberholen kannst. Jedenfalls verstand ich dein Problem so, dass du während der DB-Struktur-Änderung neue Datensätze nicht eingeben konntest...

Mich interessiert die Lösung dieses Problems aber jetzt schon: Wie hole ich die neuen Datensätze rüber? Erst recht, wenn die neue Datenbank dann mehr Spalten aufweist als die bisherige, wo die Datensätze sind?

[Pit Zyclade]

Mich interessiert die Lösung dieses Problems aber jetzt schon: Wie hole ich die neuen Datensätze rüber? Erst recht, wenn die neue Datenbank dann mehr Spalten aufweist als die bisherige, wo die Datensätze sind?

Ich bin kein Experte.
Die Spalten der Tabelle haben aber doch die alten Namen beibehalten oder? Dann wird man die Tabellen z.B. über Umweg von calc unter differentem Tabellennamen einfügen und die Daten importieren.
Ich habe soeben mal versucht, einer db1-Tabelle eine Spalte eingefügt und eine gleichnamige Tabelle in der kopierten db2 die Daten (ganz ohne SQL) rüber zuholen. Das geht direkt mit strg+V, wobei man in der Tabelle, die sich öffnet, auf der rechten Seite das zugefügte Feld, das ja leer bleiben sollte, nach unten schiebt, erst dann das Einfügen gestattet, so dass die Reihenfolge ungestört bleibt. Das geht wunderbar.

Wenn dieses Problem ansteht, kann man nur in einem konkreten Fall helfen.

[Wanderer]

...
Wie, die holt man später rüber? Einfach Copy&Paste der Tabellenzeilen?

Wenn man von Calc kommt sehe ich bei Paste in der Datenbank immer einen Import-Assistenten. Zumindestens für rechts angefügte zusätzliche Spalten sollte das also problemlos sein.

Für kompliziertere Fälle würde ich in der alten Version eine Abfrage erzeugen, die die neuen Felder mit erzeugt, dann das Ergebnis dieser Abfrage übernehmen.

PS: Ich meine hier "kleinere" Datenmengen unter 10.000 Zeilen. Ansonsten traue ich dem Clipboard nicht...