Struktur einer DB anpassen/updaten...

Installation und Anwendung von Datenbankschnittstellen wie SQLite, PostgreSQL, MySQL, der DB-API 2.0 und sonstigen Datenbanksystemen.
Benutzeravatar
jens
Moderator
Beiträge: 8458
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Struktur einer DB anpassen/updaten...

Beitragvon jens » Mittwoch 25. April 2007, 11:59

(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?

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
BlackJack

Beitragvon BlackJack » Mittwoch 25. April 2007, 12:16

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
User
Beiträge: 504
Registriert: Freitag 8. April 2005, 13:23
Wohnort: München

Beitragvon N317V » Mittwoch 25. April 2007, 15:30

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.
Es gibt für alles eine rationale Erklärung.
Außerdem gibt es eine irrationale.

Wie man Fragen richtig stellt
Benutzeravatar
jens
Moderator
Beiträge: 8458
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Beitragvon jens » Mittwoch 25. April 2007, 16:09

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...

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Benutzeravatar
Leonidas
Administrator
Beiträge: 16023
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Beitragvon Leonidas » Samstag 28. April 2007, 17:55

jens hat geschrieben: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.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
Benutzeravatar
jens
Moderator
Beiträge: 8458
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Beitragvon jens » Samstag 28. April 2007, 21:05

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

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Benutzeravatar
mitsuhiko
User
Beiträge: 1790
Registriert: Donnerstag 28. Oktober 2004, 16:33
Wohnort: Graz, Steiermark - Österreich
Kontaktdaten:

Beitragvon mitsuhiko » Samstag 28. April 2007, 23:19

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)
TUFKAB – the user formerly known as blackbird
apollo13
User
Beiträge: 827
Registriert: Samstag 5. Februar 2005, 17:53

Beitragvon apollo13 » Dienstag 1. Mai 2007, 19:50

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
Benutzeravatar
jens
Moderator
Beiträge: 8458
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Beitragvon jens » Freitag 11. Mai 2007, 07:41

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...

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Benutzeravatar
jens
Moderator
Beiträge: 8458
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Beitragvon jens » Freitag 18. Mai 2007, 12:36

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...

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
thelittlebug
User
Beiträge: 187
Registriert: Donnerstag 20. Juli 2006, 20:46
Wohnort: Wien
Kontaktdaten:

Beitragvon thelittlebug » Freitag 18. Mai 2007, 17:53

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 :D

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
Benutzeravatar
jens
Moderator
Beiträge: 8458
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Beitragvon jens » Freitag 18. Mai 2007, 19:54

thelittlebug hat geschrieben: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...

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Benutzeravatar
jens
Moderator
Beiträge: 8458
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Beitragvon jens » Samstag 2. Juni 2007, 08:45

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...

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Benutzeravatar
veers
User
Beiträge: 1219
Registriert: Mittwoch 28. Februar 2007, 20:01
Wohnort: Zürich (CH)
Kontaktdaten:

Beitragvon veers » Samstag 2. Juni 2007, 11:45

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.
Benutzeravatar
jens
Moderator
Beiträge: 8458
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Beitragvon jens » Dienstag 17. März 2009, 11:09

...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 ;)

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder