Änderung der Tabellenstruktur - problematisch?

[DataFox]

Hallo Leute

Ich denke gerade darüber nach, ob es ein ernsthaftes Problem darstellt nachträglich eine Tabellenstruktur zu verändern, wenn die Tabelle bereits viele Daten enthält.

Was kann dabei alles schief gehen? Wenn ich den Befehl gebe eine Spalte umzubenennen (inkl. anderem Datentyp), oder wenn ich eine neue Spalte hinzufüge?

Nehmen wir mal an die Tabelle hat eine Million Einträge mit 10 varchar(249) Feldern.

Welche Gründe gibt es, auf gar keinen Fall die Tabellenstruktur anzufassen? Mir wurde mal erklärt man solle sich das aus den Gedanken streichen. Ich will wissen warum! Denn bisher hatte ich damit nie Probleme.

Gruß
Laura

 

[Nico Graichen]

Hi

Also aus den Gedanken streichen würde ich das Vorhaben nicht.
Es hängt davon ab, wie die Anwendung aussieht, die auf diese Tabelle zugreift und wie groß der Ausfand ist diese an das Modell anzupassen.

Zu dem ist es eine Frage, wer diese DB nutzt.
gibt es andere Anwendungen, bei denen du keinen Zugriff auf die Sourcen hast, um diese zu ändern, sollte man nicht die DB ändern.

Dann ist es auch eine Frage, in welchen Datentyp die Spalten konvertiert werden.
Es ist interessant, mit welcher Technik auf die Datenbank zugegriffen wird.

Je nachdem kann es auch sein, dass es gar keine Auswirkungen hat.

Es kommt also immer auf die Situation an.

 

[zeja]

Mach nen dump der Datenbank, spiele diese in ein Testsystem ein, führe die Änderungen durch, schau ob alles andere damit noch funktioniert, überzeuge alle dass es so funktioniert und mache das dann im Originalsystem.

 

[DataFox]

Ich denke darüber nach ob es Sinn macht ein relativ komplexes Metadatenmodell zu fahren, oder auf herkömmliche Tabellen zu setzen. Beim Metadatenmodell können "Spalten" hinzugefügt oder geändert werden ohne auch nur im geringsten die Tabellenstruktur anzufassen. Auf den ersten Blick paradox, aber es geht wirklich.

Gruß
Laura

 

[dbwizard]

Auf den ersten Blick paradox, aber es geht wirklich.

Gruß
Laura

- Wirklich ? Immer wenn ich solche Metadatenmodelle zu sehen bekommen, muss ich meinen Fluchtinstinkt unterdrücken.

- Zur Frage des OP :

Was kann dabei alles schief gehen? Wenn ich den Befehl gebe eine Spalte umzubenennen (inkl. anderem Datentyp), oder wenn ich eine neue Spalte hinzufüge?

- Rename ist in der Regel kein Problem, jedenfalls was die Tabellenstruktur angeht. Welche Referenzen du auf das Attribut anpassen musst und wo (Code, SQL, PL/SQL ) musst du natürlich selbst wissen. Als Alternative zum Rename wäre eine View denkbar, welche den alten Atttributsnamen kapselt
- Neue Spalte zufügen : Keine Problem...Probleme könnten anschliessend eher Hässlichkeiten wie Select * from bla machen
- Datentyp wandeln : Kann nicht generell gesagt werden, kommt darauf an von welchem Typ zu welchem Typ du wandelst. Lustig sind oft die Konvertierung, wenn ein dämlicher Programmierer String-Felder zur Datumsspeicherung benutzt etc

 

[Albiorix]

- Wirklich ? Immer wenn ich solche Metadatenmodelle zu sehen bekommen, muss ich meinen Fluchtinstinkt unterdrücken.

Geht mit genauso, RDBMS heißt nun mal "Relational Database..."
Ich vermute mal, das das mit dem Metasystem in Richtung ejb3 und Annotations geht.

Ansonsten kann ich mich dir nur anschliessen (bis auf Rename, da kommt es auf die DB an, Oracle z.B. reagiert da etwas "allergisch"). Am günstigsten ist ein Datensystem, das sauber für eine Aufgabe desiged bzw. redesigned wird. Das impliziert auch mal die Umbenennung von Spalten bzw Spaltentypen.
Für nur lesenden Anwendungen, die auf meine DB zugreifen wollen, erstelle ich i.d.R. Views, die die gesamte Anwendung kapseln. Damit lassen sich eben diese Änderungen vor anderen gut verstecken und sich der Aufwand der anderen Entwickler hält sich ebenfalls in Grenzen.
Bei schreibenden Zugriffen könnte man das auch über Views mit Insteadof-Trigger realisieren.

Ansonsten, bei Änderungen kommt man ohe Testen und Datenmigration selten aus.

Sascha