Eine Datenbank updaten oder auch: Datenbank 2.0

[Klafu]

Hallo,

ich hab eben festgestellt, dass wir eine Datenbank (produktiv) haben, die man ändern müsste - also "updaten".
Man müsste entsprechende Änderungen an ihr vornehmen wie z.B.  Namen von Masken ändern aber auch Feldnamen anpassen. Das ganze hätte "lediglich" den Sinn, die Datenbank strukturierter zu machen und sie auch so für Dritte besser Nachvollziehbar gestalten.
Und wie ich grad so drüber nachdenke und mir der Aufwand bewusst wird, bin ich schon wieder dabei die Idee zu verwerfen. 
Allerdings wollte ich trotzdem einmal Nachfragen wie ihr das Handhabt.
Macht ihr überhaupt so schwerwiegende Änderungen an bestehnenden Datenbanken?
Macht es mehr Sinn die Datenbank neu zu erstellen und dann die Daten neu zu importieren?
Oder versucht ihr das ganze so weit wie Möglich zu vermeiden?

Grüße
Chris

[Driri]

Redesigns oder wie man das nennen möchte habe ich schon ein paar hinter mir. Allerdings waren das entweder rein optische Geschichten (z.B. weg von den Navigatoren aus R5, neues CI, Änderung von Beschrifungen nach der Fusion, etc.) oder die Migration mehrerer bestehender Anwendungen in eine neue, gemeinsame Anwendung.

Der erste Fall ist relativ überschaubar, da man da ja eigentlich nur an den Designelementen rumdreht und nicht die Daten/Dokumente anfassen muß.

Der zweite Fall kann aber auch recht komplex werden. Ich habe hier gerade aus neun bestehenden Anwendungen eine gemacht und das ist nicht ohne Migrationsagenten abgelaufen. Dabei mußten nicht nur die Form ausgetauscht werden, sondern auch Items umgeschrieben und vor allem massiv Leserfelder auf eine neue, komplexere Rechtestruktur umgebogen werden.

Ob neu machen oder in der bestehenden die Dokumente migrieren, hängt denke ich mal wesentlich auch von der Komplexität der Anwendung ab. Wenn z.B. intern die UNID der Dokumente für irgendwas verwendet wird (Verlinkung oder so), dann muß man beim Importieren der Dokumente in eine neue Datenbank natürlich einiges mehr beachten.

Vermeiden würde ich es schon. Aber manchmal hat man auch einfach keine Wahl oder es macht einfach keinen Sinn, so eine Umstellung nicht durchzuführen. Das kann ja auch durchaus positive Nebeneffekte haben. Wenn ich die Zeit dafür hätte, würde ich z.B. auch gerne mal ein paar meiner Erstwerke neu aufbauen.

[Klafu]

Vielen Dank für die Einblicke, Ingo!
Freu mich über alle Erfahrungsberichte. Vielleicht äußern sich ja noch ein paar zu diesem Thema.
Mir ist da auch die Helpdeskdatebank eingefallen die es ja auch in verschiedenen Versionen gibt. Aber da sind die Änderungen vielleicht nicht so krass gewesen, oder?

[Thomas Schulte]

!!HELP!! ? Oh doch da hat sich in den verschiedenen Versionen einiges geändert. Für bestimmte Versionssprünge haben wir dann Update Scripte geschrieben. Entscheidend für so was ist, das man die Anwendung die da existiert wirklich GUT kennen muss. Und wenn man sie nicht bis zur letzten Schraube im hintersten Winkel kennt, dann muss man sie kennen lernen. notes macht es einem Hier bedingt durch die grundlegenden Annahmen des Systemes an und für sich allerdings nicht besonders einfach.

[Klafu]

Ja, die meinte ich, Thomas.
Dir auch Danke. Das heißt man "könnte" alle Dokumente im BackEnd durchgehn und den Namen der Maske mit doc.Form="Neue Maske" ändern.
Wie gehe ich dann bei Felder vor? Nehme ich ein Feld, hol mir dessen Wert, erzeuge ein neues Item mit dem Namen das neuen Feldes, schreib den Wert wieder hinein und lösche das alte Item?

[Thomas Schulte]

Im wesentlichen schon. Nur must du außerdem noch nachschauen, ob es das Item vielleicht mehrfach im Dokument gibt. Das ist ja eine der Spezialitäten für die dieses System bekannt ist.
Dann kommen noch so Dinge wie püfen ob das Format korrekt ist und noch ein paar andere Sachen die mir auf die Schnelle nicht einfallen auf Item Ebene dazu. Wenn du Aliaswerte geändert hast, musst du die auch berücksichtigen. Und so weiter ...

[Klafu]

Nun weis ich in etwa wie groß ein solches Projekt werden kann 
Danke!

Chris

[Bastel123]

Hallo,

man sollte bei einem Update auf Release 2.0 auch grundsätzlich die Funktionalitäten überdenken.

Kann alles so bleiben, oder nutze ich das Ganze um auch die Prozesse zu ändern. Dann muss man vorher und meistens auch noch nachher die Daten bereinigen und die Leichen verschwinden lassen.

Dafür braucht man nicht nur den Programmierer, sondern auch Leute die sich fachlich in der Datenbank auskennen.

Aber man wird belohnt mit einer schön aufgeräumten Datenbank.

Bis dann Release 3.0 ansteht :-).

Gruß Sebastian

[flaite]

Gibt halt an Anwendungen oft neue Anforderungen.
Und das wird dann gerne mit wilden if-Verzweigungen tief hinten im code abgefrühstückt.
Irgendwann wird dann die Anwendung als "inder-sicher" erklärt, d.h. das man nur noch 1 Mann in der Firma in das Minenfeld schicken kann, um Änderungen vorzunehmen. Es werden dann Witze darüber gerissen, dass wenn der vom Bus überfahren wird...

Obs Sinn macht oder nicht kann nur Fallweise entschieden werden. Hängt von vielen Parametern ab. Wie wahrscheinlich sind Änderungen? Werden in Zukunft ähnliche Anwendungen entwickelt, für die die inder-sichere Anwendung als "Vorbild" dient? Wie hoch ist die Wahrscheinlichkeit, dass man bei der Neuprogrammierung eben doch nicht alle Anwendungsfälle beachtet? etc. etc.

Zur Zeit mach ich sowas als Externer in JEE. Ist auch ein psychologisches Minenfeld. Der auf seine Art sehr gute ursprüngliche Entwickler ist ein sehr ausgeprägter was-Typ (s. Vichenow, Schneider, Soft-Skills für Software-Entwickler). Die Meinungen des Teams sind für refactoring, weil wenn der in Urlaub fährt... Aber ich will in dieser verdammten IT-Welt Grabenkriege verhindern. Nix mehr von dieser abgründigen Scheisse.
Man muß natürlich die innere und äußere Funktionalität der Anwendung sehr, sehr, sehr, sehr detailliert analysieren, verstehen und kennen. Auch die zugreifenden Systeme.

Es ist nicht einfach, aber mir kann sowas auch Spaß machen. Naja, nach tagelangen Grass fressen ;-) für 20 Minuten. Und dann immer die Befürchtung, dass sich der ursprüngliche Erbauer bedrängt fühlt. Und dass ich am Ende dann doch etwas übersehen habe.

Viele der Methodiken + unterstützende Tools in der Java-Welt der letzten Jahre wie automatisiertes Testen, Continuous Integration, massiver Einsatz von Standardisierten Frameworks unterstützen stark die Richtung des Refactorings, also die innere Struktur der Anwendung zu verändern, um zukünftige Erweiterungen zu erleichtern, also die wo du Datenbank 2.0 nennst. Bleiben aber viel Anwendungs-spezifische Aspekte.

a pain in the ass, aber mein Opa ist 30 Jahre bei Wind und Wetter auf einen Kran geklettert und hat 8 Stunden Schiffe ent- und beladen.

[Klafu]

Es sieht wohl ganz so aus, wie ich befürchtet hatte. Das Groß-Projekt macht nur Sinn, wenn die Notwendigkeit nicht nur von einem Mitarbeiter, sondern auch von einer höheren Ebene entdeckt und/oder verstanden wird. Ansonsten steht der Aufwand nicht in Relation zum Nutzen. Es läuft, aber eben nicht ganz so schön.
Von demher ist es aber gut, nun einen Einblick zu haben, wie man ein solchens Projekt aufziehen kann/muss.
Danke für die Denkanstöße!

Chris