Struktur einer DB anpassen/updaten...

[jens]

(sorry für noch einen Thread)

Also irgendwie ist das ändern von Datenbank Tabellen doch ein allgemeines Problem. Es müssten doch eigentlich fast alle Leute haben, die was mit DBs anstellen...

Ein erster Datenbank-Entwurf ist doch nie perfekt. Hier fehlt noch eine Spalte, da müssten noch Anpassungen gemacht werden usw.

SQLAlchemy und das django ORM gehen dem ganz aus dem Weg und kümmern sich das IMHO überhaupt nicht drum.

Wenn man SQLite verwendet, hat man eh Probleme diese im nachhinein anzupassen, siehe: http://www.python-forum.de/topic-10372.html

Gibt es da keine Allgemeine Lösungsansätze für? Oder zumindest Tools die dabei helfen?

[BlackJack]

Das ist wohl einer der Gründe dafür, warum ein Bekannter von mir, ein Oracle-zertifizierter Mensch, der sich beruflich mit Datenbanken beschäftigt, sagt, dass Datenbankentwürfe einmal gemacht werden und dann *feststehen*.

So eine "harmlose" Änderung wie das hinzufügen, entfernen oder ändern einer Spalte kann bei Änderung der Datensatzgrösse eine ganze Menge Aufwand für das DBMS zur Folge haben. Bei den meisten Arten die Datenätze effizient zu speichern, ist die Datensatzgrösse wichtig, d.h. wenn man die ändert, muss die ganze Tabelle auf der Platte umkopiert und reorganisert werden.

Da ist also vom Rechen- oder besser I/O-Aufwand das "dumpen" und "droppen" der alten Tabelle und das neuladen in die neue Tabelle, gar nicht so viel aufwändiger. Zudem hat man auch gleich ein Backup vom Zustand der Tabelle vor der Veränderung.

[N317V]

Das ist auch einer der Gründe, warum Datenbankdesign das einzige ist, das ich freiwillig mit Stift und Papier mache. Erst wenn es dann auf Papier perfekt ist, setz ich mich an den Rechner.

[jens]

Naja, ist schon klar, das es gut ist, wenn man direkt am Anfang die Perfekte DB hat... Aber die Ansprüche ändern sich mit der Zeit...

Das mit dem Dump ziehen -> neue DB erstellen -> Dump einspielen ist gar nicht mal so schlecht. Wobei, wenn ein ALTER TABLE bei MySQL Ausreicht, ist das schneller gemacht

Aber auch mit der Dump Lösung hat man immer noch das Problem mit den verschiedenen SQL-DBs... Es ist also recht einfach sowas wie SQLAlchemy zu nehmen und damit die Abfragen zu machen... Aber wenn sich die DB ändern soll, hilft auch SQLAlchemy und alle anderen nicht weiter Schade...

[Leonidas]

Aber wenn sich die DB ändern soll, hilft auch SQLAlchemy und alle anderen nicht weiter Schade...

Das Django ORM kann soweit ich weiß die Datensätze in andere Formate (XML, JSON) serialisieren. Das hat aber beim letzten Mal leider nicht so funktioniert wie ich gehofft habe.

[jens]

Bei mir auch nicht Deswegen hab ich das externe db_dump genommen, das funktionierte besser...

[mitsuhiko]

Datenbankstrukturen sollten sich nur wärend der Entwicklungszeit ändern. Und da arbeitet man nur mit Testdaten. Und wenn man ein Datenbankupgrade von eienr Version auf die andere braucht weil ein Feature dazugekommen ist macht man am Besten eine neue Tabelle und joined ein wenig.

Ansonsten gibts noch den Weg über eine temporäre Tabelle (ALTER TABLE wird nicht von jeder Datenbank unterstützt)

[apollo13]

Naja, ob eine neue Tabelle so sinnvoll ist?
Da bin ich persönlich eher für Dump, ändern und neuneinspielen...
Sollte ja nicht allzu oft vorkommen

[jens]

Das ist ja mal was interessantes für django: http://www.aswmc.com/dbmigration/

Es verspricht auf dem ersten Blick viel:

Django is excellent at creating a schema from your models. A simple syncdb command will generate sql and install your schema. Currently, the main Django trunk has no way of migrating a schema to a new structure. So if you want to change your model structure and roll this new structure out to a live site, you have to write sql scripts to change the structure so that it fits your new model.
...
This project attempts to allow automatic schema migration for Django applications in a completely automated way.
...

Wenn man sich das genauer ansieht, macht es allerdings nichts anderes, was ich in meiner _install Sektion eh schon mache.
Das man bei SQLite die Tabellen im nachhinein nicht mehr ändern kann, löst auch das Tool nicht wirklich...

[jens]

Genau um das Thema "anpassen einer bestehenden Datenbank" dreht sich der django Branch "SchemaEvolution":
http://code.djangoproject.com/wiki/SchemaEvolution
http://code.djangoproject.com/wiki/Sche ... onProposal
Der passende Thread auf der dev-Liste:
http://groups.google.com/group/django-d ... a4b239e844

Damit soll man dann auf einfache Weise Datenbanken updaten können.

Allerdings weiß ich nicht wie der Status ist

Im SVN gibt es:
http://code.djangoproject.com/browser/d ... -evolution
(letzte Änderung 7 Monate her)

und es gibt:
http://code.djangoproject.com/browser/d ... olution-ng
(letzte Änderung 4 Monate her)

Ist somit wohl ein wenig eingeschlafen...

[thelittlebug]

Ich kenne jemanden der bei einer Firma als Datenbankkonvertierer angestellt ist.
Die machen den ganzen Tag nichts anderes als misslungene DB-Designs von "selfmade"-Warenwirtschaftssystemen auszubessern. Das ganze in Perl und diversen Kostenpflichtigen Tools. (Mapping)

Gebe es eine simple Lösung die die Daten beim Konvertieren beachten würde wäre dieser Job überlüssig. Das Geschäft läuft aber gut

Auch bei der Sage OfficeLine ist bei einem Update der Version ein ganzer Haufen TSQL Scripts dabei die sich nur um das Konvertieren kümmern. Die Entwicklerkommentare bei den einzelnen qry's zeigen mir auch das da echte "manpower" dahinter steckt. Ich bezweifle das du eine Lösung finden wirst die die DB oder die Tabellen nicht neu aufbaut.

Der Weg über temporäre Tabellen ist meiner Meinung nach immer gut da man sich nie sicher sein kann ob die Konvertierung z.b. abbricht. Da ist es dann schon "nice" wenn man die Originaltabelle noch hat

Viele Datenbanken unterstützen das ändern von Tabellen im nachhinein gar nicht oder nur zum Teil. Spätestens wenn ein Datumsfeld in einen String umgewandelt werden soll würde ich auch gerne wissen was umgewandelt wird

Man könnte ewig weiterschreiben, aber ich glaub die restlichen 3,2**19 Gründe kann sich jeder selbst ausdenken.

lg herby

[jens]

Spätestens wenn ein Datumsfeld in einen String umgewandelt werden soll würde ich auch gerne wissen was umgewandelt wird

Sowas hatte ich natürlich auch schon... Das mache ich dann in Python selber...

Aber im Grunde sind das ja auch immer wieder die selben Dinge... Alle EInträge einer Spalte ändern...
Ich weiß nicht in wie fern da SchemaEvolution einen Arbeit abnimmt...

[jens]

Ich habe in der zwischenzeit das update Verfahren doch geändert: http://pylucid.net/trac/browser/branche ... /update.py

Nun mache ich es doch so:
1. django erzeugt mit syncdb die neuen Tabellen
2. Mein Skript kopiert die Daten aus den alten Tabellen in die neuen um.

Das ist erstmal für das Update von der alten PyLucid Version auf die neue PyLuciod+django Version.

Ich frage mich allerdings wie ich das zukünftig handhaben sollte. Eine Idee ist die folgende: Wenn ich änderungen an einem DB Modell vornehmen sollte, mache ich vorab eine Kopie der Modell-Klasse und benenne sie um (z.B.: Page -> Page_old).
Nun kann ich in der Update Routine auf beide Tabellen/Modelle zugreifen und muß dann die Daten umkopieren.

Mit diesem Verfahren (also ohne "ALTER TABLE") würde es auch mit SQLite funktionieren.

Das ist natürlich etwas Aufwendig, wenn man nur eine Kleinigekeit ändern, die man in MySQL mit einem einzigen "ALTER TABLE" Statement umsetzten könnte. Aber naja...

[veers]

http://www.djangosnippets.org/snippets/14/ damit habe ich die DB auf swiss-bash migriert. Hat gut funktioniert. Inwiefern das sich mit grösseren Änderungen am Schema verträgt weis ich nicht.

[jens]

...altes Thema ausbuddeln...

Im Jan.2009 wurde ein neues Projekt auf http://code.djangoproject.com/wiki/SchemaEvolution verlinkt: http://south.aeracode.org/
Noch ist es aktiv. Mal sehen was daraus wird