FOREIGN KEY

Hi!

Ich habe eine recht komplexe Tabellenstruktur. Um die Konsistenz sicher zu=
=20
stellen, habe ich exzessiven Gebrauch von FOREIGN KEY gemacht. Jetzt kam ei=
n=20
Refactoring der DB und dutzende Tabellen und Spalten wurden umbenannt.
Seid dem ist die Konsistenz nicht mehr durch FOREIGN KEY geschützt. Ic=
h weiß=20
nicht ob tatsächlich das eine mit dem anderen zu tun hat. Ist nur eine=
=20
Vermutung von mir. CONSTRAINTs sind noch da, aber ich kann wild alles l=C3=
=B6schen=20
ohne das mir die DB einhalt gebietet. Also: Wenn Tabellen und Spalten=20
umbenannt werden, gehen dabei dann die Verknüpfungen der FOREIGN KEY=
=20
verloren?

Gruß

Olaf

--=20
Meine Rechtschreibfehler stehen unter der Creative Commons Lizenz.
(Bearbeitungen und Weitergabe unter gleichen Bedingungen):
http://creativecommons.org/licenses/by-sa/2.0/de/

--=20
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

Re: FOREIGN KEY

Olaf Radicke schrieb:

> Hi!
>=20
> Ich habe eine recht komplexe Tabellenstruktur. Um die Konsistenz sicher=
zu=20
> stellen, habe ich exzessiven Gebrauch von FOREIGN KEY gemacht. Jetzt ka=
m ein=20
> Refactoring der DB und dutzende Tabellen und Spalten wurden umbenannt.
> Seid dem ist die Konsistenz nicht mehr durch FOREIGN KEY geschützt. I=
ch weiß
> nicht ob tatsächlich das eine mit dem anderen zu tun hat. Ist nur ein=
e=20
> Vermutung von mir. CONSTRAINTs sind noch da, aber ich kann wild alles l=
öschen=20
> ohne das mir die DB einhalt gebietet. Also: Wenn Tabellen und Spalten=20
> umbenannt werden, gehen dabei dann die Verknüpfungen der FOREIGN KEY=20
> verloren?

Welche Version? Und warum prüfst Du es nicht?

test=3D# create table t1 (id int primary key);
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "t1_pkey"
for table "t1"
CREATE TABLE
Zeit: 6,651 ms
test=3D*# create table t2 (id int references t1);
CREATE TABLE
Zeit: 4,305 ms
test=3D*# alter table t1 rename column id to id_new;
ALTER TABLE
Zeit: 0,406 ms
test=3D*# \d t2
Tabelle =BBpublic.t2=AB
Spalte | Typ | Attribute
--------+---------+-----------
id | integer |
Fremdschlüssel-Constraints:
=BBt2_id_fkey=AB FOREIGN KEY (id) REFERENCES t1(id_new)

Und nun mal schauen, was passiert:

test=3D*# insert into t2 values (1);
ERROR: insert or update on table "t2" violates foreign key constraint
"t2_id_fkey"
DETAIL: Key (id)=3D(1) is not present in table "t1".


Okey, und nun mit RENAME der Tabelle:

test=3D*# rollback;
ROLLBACK
Zeit: 0,680 ms
test=3D# create table t1 (id int primary key);
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "t1_pkey"
for table "t1"
CREATE TABLE
Zeit: 11,563 ms
test=3D*# create table t2 (id int references t1);
CREATE TABLE
Zeit: 1,614 ms
test=3D*# alter table t1 rename to new_t1;
ALTER TABLE
Zeit: 19,189 ms
test=3D*# \d t2
Tabelle =BBpublic.t2=AB
Spalte | Typ | Attribute
--------+---------+-----------
id | integer |
Fremdschlüssel-Constraints:
=BBt2_id_fkey=AB FOREIGN KEY (id) REFERENCES new_t1(id)

test=3D*# insert into t2 values (1);
ERROR: insert or update on table "t2" violates foreign key constraint
"t2_id_fkey"
DETAIL: Key (id)=3D(1) is not present in table "new_t1".
test=3D!#=20





Andreas
--=20
Really, I'm not out to destroy Microsoft. That will just be a completely
unintentional side effect. (Linus Torvalds)
"If I was god, I would recompile penguin with --enable-fly." (unknown)
Kaufbach, Saxony, Germany, Europe. N 51.05082°, E 13.56889=
°

--=20
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.o=
rg)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

Re: FOREIGN KEY

Am Sunday 25 January 2009 21:49:37 schrieb Andreas Kretschmer:
> Welche Version? Und warum prüfst Du es nicht?

Die DB besteht aus ca. 60 Tabellen, und noch mal ca. FOREIGN KEY. Ich habe =
mir=20
mit gpAdminIII die Tabellen angesehen. Und danach gab es einen FOREIGN KEY=
=20
auf eine bestimmte Tabelle. Mein DB-Anwendung konnte aber ungestraft=20
Datensätze löschen.=20
Jetzt habe ich die DB noch mal mit psql untersucht und festgestellt das die=
=20
FOREIGN KEY in einer anderen Tabelle existieren und funktionieren, nur in d=
em=20
einen Fall, sagte psql auf einmal es gäbe für die Tabelle kein FOREIGN =
KEY.=20
Als ich den händisch noch mal nachgebaut habe, konnte meine DB-Anwendung =
auch=20
nicht mehr herum wüten.=20
Also, PostgreSQL trifft keine Schuld. Mit pgAdminIII ist nicht immer=20
zuverlässig. So fragt mich das Tool jedesmal nach dem Passwort der DB und=
=20
jedes mal fragt pgAdminIII ob es das Passwort speichern soll, und jedes mal=
=20
sage ich "ja" und trotzdem werde ich wieder nach dem Passwort gefragt.

Ich sitze jetzt in dem Dilemma, das ich jetzt nicht genau weiß, wie die=
=20
aktuellen Tabellen meiner Anwender meiner Software aussehen. Mit jedem Upda=
te=20
wächst die Gefahr, das die Tabellen die durch eine Neuinstallation angele=
gt=20
werden, anders aussehen, als die, die den Update-Prozess durchlaufen haben.=
=20
Durch das Refactoring wurde das Problem auch noch verschärft.=20

Vielleicht muss ich für den Upgrade einfach Test schreiben um herraus zu=
=20
bekommen, ob die Tabellen so aussehen wie sie sollen. Also Dummy-Datensät=
ze=20
schreiben, lesen und löschen. Oh, mich grausts... Nur allein das=20
Refactoring-Upgrade hat schon 1500 Zeilen SQL.

MfG

Olaf


--=20
Meine Rechtschreibfehler stehen unter der Creative Commons Lizenz.
(Bearbeitungen und Weitergabe unter gleichen Bedingungen):
http://creativecommons.org/licenses/by-sa/2.0/de/

--=20
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

Re: FOREIGN KEY

Hallo,

On Mon, 26 Jan 2009 00:20:53 +0100 Olaf Radicke wrote:

> Am Sunday 25 January 2009 21:49:37 schrieb Andreas Kretschmer:
>=20
> Also, PostgreSQL trifft keine Schuld. Mit pgAdminIII ist nicht immer=20
> zuverlässig. So fragt mich das Tool jedesmal nach dem Passwort der D=
B und=20
> jedes mal fragt pgAdminIII ob es das Passwort speichern soll, und jedes m=
al=20
> sage ich "ja" und trotzdem werde ich wieder nach dem Passwort gefragt.

Das funktioniert hier ohne Probleme. Aber so oft nutze ich pgAdminIII
nicht.

Wenn pgAdminIII allerdings Daten oder Strukturen falsch anzeigt, sind
die Maintainer sicherlich an einem Bugreport samt passendem Test
interessiert.



> Ich sitze jetzt in dem Dilemma, das ich jetzt nicht genau weiß, wie =
die=20
> aktuellen Tabellen meiner Anwender meiner Software aussehen. Mit jedem Up=
date=20
> wächst die Gefahr, das die Tabellen die durch eine Neuinstallation a=
ngelegt=20
> werden, anders aussehen, als die, die den Update-Prozess durchlaufen habe=
n.=20
> Durch das Refactoring wurde das Problem auch noch verschärft.=20

Nun, psql zeigt die Informationen doch richtig an, oder? Wo ist das
Problem?

Wenn sich allerdings Update und Neuinstallation unterscheiden, ist euer
Update Prozess gehörig faul. Wie genau schaut so ein Update bei euch
aus?



> Vielleicht muss ich für den Upgrade einfach Test schreiben um herrau=
s zu=20
> bekommen, ob die Tabellen so aussehen wie sie sollen. Also Dummy-Datens=
ätze=20
> schreiben, lesen und löschen. Oh, mich grausts... Nur allein das=20
> Refactoring-Upgrade hat schon 1500 Zeilen SQL.

*brr* Testdaten in einer Produktivumgebung? Was genau wird das zum
Schluss? Die Tabellenstruktur kann man auch ohne Testdaten
herausfinden. Da gibt es zum einen "information_schema" und zum anderen
die Systemkataloge. Beides kann man abfragen und die Struktur
herausfinden.

1500 Zeilen Update Code? Hört sich erst mal nicht wirklich viel an.


Bis dann

--=20
Andreas 'ads' Scherbaum
German PostgreSQL User Group
European PostgreSQL User Group - Board of Directors

--=20
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

Re: FOREIGN KEY

Am Monday 26 January 2009 12:46:09 schrieb Andreas 'ads' Scherbaum:
> Hallo,
>
> On Mon, 26 Jan 2009 00:20:53 +0100 Olaf Radicke wrote:
> > Am Sunday 25 January 2009 21:49:37 schrieb Andreas Kretschmer:
> >
> > Also, PostgreSQL trifft keine Schuld. Mit pgAdminIII ist nicht immer
> > zuverlässig. So fragt mich das Tool jedesmal nach dem Passwort der=
DB und
> > jedes mal fragt pgAdminIII ob es das Passwort speichern soll, und jedes
> > mal sage ich "ja" und trotzdem werde ich wieder nach dem Passwort
> > gefragt.
>
> Das funktioniert hier ohne Probleme. Aber so oft nutze ich pgAdminIII
> nicht.

Ich verwende hier Version 1.4.8 unter Debian testing.


> > Ich sitze jetzt in dem Dilemma, das ich jetzt nicht genau weiß, wi=
e die
> > aktuellen Tabellen meiner Anwender meiner Software aussehen. Mit jedem
> > Update wächst die Gefahr, das die Tabellen die durch eine Neuinsta=
llation
> > angelegt werden, anders aussehen, als die, die den Update-Prozess
> > durchlaufen haben. Durch das Refactoring wurde das Problem auch noch
> > verschärft.
>
> Nun, psql zeigt die Informationen doch richtig an, oder? Wo ist das
> Problem?
>
> Wenn sich allerdings Update und Neuinstallation unterscheiden, ist euer
> Update Prozess gehörig faul. Wie genau schaut so ein Update bei euch
> aus?

Also. Hier findest du die Aktuelle Version:
http://sourceforge.net/project/showfiles.php?group_id=3D1826 73&package_id=
=3D241269
Als LiveCD mit "sudo su" und "su postgres" wirst du dir die DB detailliert=
=20
ansehen können.

Unter=20
http://sourceforge.net/project/showfiles.php?group_id=3D1826 73&package_id=
=3D307319

Findest du eine LiveCD mit einem SVN-Snapshot vom 23.1.09=20

Und hier findest du das geplante Update von 0.x.x auf 1.x.x:
http://artikel23.svn.sourceforge.net/viewvc/artikel23/trunk/ doc/table_updat=
es/update_1.0.0.sql?view=3Dlog

Ich will ja nicht ausschlissen, das wir was vergurkt haben, beim=20
Programmieren. Das Programm kommuniziert über die Lib npsql mit Postgr=
eSQL=20
und die war/ist auch nicht Fehlerfrei. So gab es z.B. Probleme mit dem=20
Maskieren von Sonderzeichen (Funktionszeichen). Zu dem habe ich die=20
Entwicklerdatenbank unzählige male mit fehlerhaften Programmen oder Te=
sts=20
zerschossen und immer wieder neu eingespielt. In den Letzten zwei Jahren de=
r=20
Entwicklung habe ich das Programm auf meinen PC knapp 33.000 mal neu=20
übersetzt und getestet. Es währe ein Wunder, wenn sich da keine F=
ehler=20
eingeschlichen hätten. Die große Preisfrage lautet: wie gehe ich =
am besten=20
damit um und wie kann ich sicherstellen, das alle nach dem Upgrade die=20
Gleichen Tabellenstruckturen haben?=20

> > Vielleicht muss ich für den Upgrade einfach Test schreiben um herr=
aus zu
> > bekommen, ob die Tabellen so aussehen wie sie sollen. Also
> > Dummy-Datensätze schreiben, lesen und löschen. Oh, mich graus=
ts... Nur
> > allein das Refactoring-Upgrade hat schon 1500 Zeilen SQL.
>
> *brr* Testdaten in einer Produktivumgebung? Was genau wird das zum
> Schluss? Die Tabellenstruktur kann man auch ohne Testdaten
> herausfinden. Da gibt es zum einen "information_schema" und zum anderen
> die Systemkataloge. Beides kann man abfragen und die Struktur
> herausfinden.

Den Vorteil von Testdaten sehe ich darin, das man prüft, welche Operat=
ionen=20
alle gehen müssen und welche nicht gehen dürfen. Bei Fehlern such=
t man dann=20
nach der Ursache, die vielerlei Gründe haben kann. Gut, das mit einem=
=20
Produktivsystem zu machen, ist wahrscheinlich nicht so eine glorreiche Idee=
..=20
Aber als Entwicklertool? Ein vorgeschlagener Weg, fängt das Problem vo=
n der=20
anderen Seite an aufzurollen. Den Nachteil den ich sehe ist, das man=20
eigentlich das Problem schon kennen muss, um sinnvolle Tests zu machen.=20
Ansonsten gibt es einfach zufiel worauf man testen könnte.

MfG

Olaf


--=20
Meine Rechtschreibfehler stehen unter der Creative Commons Lizenz.
(Bearbeitungen und Weitergabe unter gleichen Bedingungen):
http://creativecommons.org/licenses/by-sa/2.0/de/

--=20
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

Re: FOREIGN KEY

On Mon, 26 Jan 2009 18:33:07 +0100 Olaf Radicke wrote:

> Am Monday 26 January 2009 12:46:09 schrieb Andreas 'ads' Scherbaum:
>=20
> Und hier findest du das geplante Update von 0.x.x auf 1.x.x:
> http://artikel23.svn.sourceforge.net/viewvc/artikel23/trunk/ doc/table_upd=
ates/update_1.0.0.sql?view=3Dlog

Wenn es nur eine vorherige Version gibt, ist das doch ok. Ansonsten
bräuchtest du Intermediate Skripts von jeder Version auf die näch=
ste
und du solltest nicht versuchen, von jeder beliebigen vorherigen
Version mit Hilfe von einem einzelnen Skript auf den gleichen Stand zu
kommen.


Ein paar Anmerkungen zu dem Skript vielleicht noch:


> UPDATE mitglied SET geburtsdatum =3D DATE'1753-01-01' WHERE
> geburtsdatum IS NULL;

Wie kommt man denn auf die Idee, statt NULL ein veraltetes Datum
einzuführen?


> UPDATE mitglied SET geschlecht =3D '' WHERE
> geschlecht IS NULL;

Auch wenn ich es nur ungern sage, aber ein TEXT ist hier oversized, ein
CHAR(1) würde wahrscheinlich ausreichen. Dazu fehlt ein CHECK auf die
möglichen Werte - oder ggf. doch ein ENUM.


> postleitzahl INTEGER NOT NULL

Das könnte euch böse Probleme bereiten bei führenden Nullen.
Das Land fehlt auch völlig. Es gibt Länder mit 4-stelligen
Postleitzahlen und welche mit 5 Stellen, bei denen die führende aber 0
ist. Wie unterscheidet man so etwas?


> fax_oder_tel TEXT NOT NULL

Was ist mit optionalen Handynummern, einer Sammelnummer und einer
Durchwahl?


> stellen_anzahl INTEGER
> geschlecht TEXT

Gibt es nur Stellen für Frauen XOR für Männer?


> ALTER TABLE stelle RENAME COLUMN geschlecht TO salutation;

"gender" wäre hier ev. besser passend, je nachdem welchen Zweck dieses
Feld genau erfüllt.


Ach, ich höre auf.




=20
> Ich will ja nicht ausschlissen, das wir was vergurkt haben, beim=20
> Programmieren. Das Programm kommuniziert über die Lib npsql mit Post=
greSQL=20
> und die war/ist auch nicht Fehlerfrei. So gab es z.B. Probleme mit dem=20
> Maskieren von Sonderzeichen (Funktionszeichen). Zu dem habe ich die=20
> Entwicklerdatenbank unzählige male mit fehlerhaften Programmen oder =
Tests=20
> zerschossen und immer wieder neu eingespielt. In den Letzten zwei Jahren =
der=20
> Entwicklung habe ich das Programm auf meinen PC knapp 33.000 mal neu=20
> übersetzt und getestet. Es währe ein Wunder, wenn sich da keine=
Fehler=20
> eingeschlichen hätten. Die große Preisfrage lautet: wie gehe ic=
h am besten=20
> damit um und wie kann ich sicherstellen, das alle nach dem Upgrade die=20
> Gleichen Tabellenstruckturen haben?=20

Du hast doch eine Tabelle mit Versionsnummern. Und du weisst
hoffentlich noch, welche Änderungen sich von Version zu Version ergeben
haben. Die spielst du nacheinander ein.



> Den Vorteil von Testdaten sehe ich darin, das man prüft, welche Oper=
ationen=20
> alle gehen müssen und welche nicht gehen dürfen. Bei Fehlern su=
cht man dann=20
> nach der Ursache, die vielerlei Gründe haben kann. Gut, das mit eine=
m=20
> Produktivsystem zu machen, ist wahrscheinlich nicht so eine glorreiche Id=
ee.

Woher kannst du dir sicher sein deine Testdaten hinterher alle wieder
aufzuräumen? Wenn du welche vergisst - wandern diese als
Produktionsdaten in deine Datenbank.



> Aber als Entwicklertool? Ein vorgeschlagener Weg, fängt das Problem =
von der=20
> anderen Seite an aufzurollen. Den Nachteil den ich sehe ist, das man=20
> eigentlich das Problem schon kennen muss, um sinnvolle Tests zu machen.=
=20
> Ansonsten gibt es einfach zufiel worauf man testen könnte.

Das hört sich so an als ob nachträglich Tests eingeführt wer=
den, obwohl
oder gerade weil der Versionsstand der Datenbank nicht bekannt ist?

In dem Fall müsst ihr wohl wirklich einfach durch und die Probleme in
Kauf nehmen.


Bis dann

--=20
Andreas 'ads' Scherbaum
German PostgreSQL User Group
European PostgreSQL User Group - Board of Directors

--=20
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

Re: FOREIGN KEY

Am Monday 26 January 2009 21:59:00 schrieb Andreas 'ads' Scherbaum:
> On Mon, 26 Jan 2009 18:33:07 +0100 Olaf Radicke wrote:
> > Am Monday 26 January 2009 12:46:09 schrieb Andreas 'ads' Scherbaum:
> >
> > Und hier findest du das geplante Update von 0.x.x auf 1.x.x:
> > http://artikel23.svn.sourceforge.net/viewvc/artikel23/trunk/ doc/table_u=
pd
> >ates/update_1.0.0.sql?view=3Dlog
>
> Wenn es nur eine vorherige Version gibt, ist das doch ok. Ansonsten
> bräuchtest du Intermediate Skripts von jeder Version auf die nä=
chste
> und du solltest nicht versuchen, von jeder beliebigen vorherigen
> Version mit Hilfe von einem einzelnen Skript auf den gleichen Stand zu
> kommen.

Das tut es auch nicht. Wenn man versucht ein Update ein zu spielen was nich=
t=20
passt, wird das abgebrochen und mit Fehlermeldung wieder aufgerollt.

> Ein paar Anmerkungen zu dem Skript vielleicht noch:
> > UPDATE mitglied SET geburtsdatum =3D DATE'1753-01-01' WHERE
> > geburtsdatum IS NULL;

Das ist eine saublöde Beschränkung in .Net-Runtime/Mono-Runtime. =
Eigentlich=20
hätte ich 1.1.01 haben mögen. Das verursacht aber ein Crash. V=C3=
=B6llig absurde=20
Geschichte. Das ist eigentlich ein Limit von MS-SQL und wurde verschleppt.=
=20

> Wie kommt man denn auf die Idee, statt NULL ein veraltetes Datum
> einzuführen?

Das Datum soll anzeigen, das was nicht stimmt. Es gibt Probleme mit C# bequ=
em=20
auf NULL zu testen. Deswegen auch nicht NULL. Nirgends in Tabellen (fast,=
=20
jedenfalls).

> > UPDATE mitglied SET geschlecht =3D '' WHERE
> > geschlecht IS NULL;
>
> Auch wenn ich es nur ungern sage, aber ein TEXT ist hier oversized, ein
> CHAR(1) würde wahrscheinlich ausreichen. Dazu fehlt ein CHECK auf die
> möglichen Werte - oder ggf. doch ein ENUM.

Die Spalte hat ihre Bedeutung verändert. Ursprünglich sollte mal =
ein "Maching"=20
darüber gemacht werden. Jetzt wird da nurnoch Namensvorsätze abge=
kippt, ohne=20
weiter damit zu arbeiten. Da steht jetzt alles drinnen von "Herr", "Frau"=
=20
bis "Oberstudienrat" und "General ad."

> > postleitzahl INTEGER NOT NULL
>
> Das könnte euch böse Probleme bereiten bei führenden Nulle=
n.
> Das Land fehlt auch völlig. Es gibt Länder mit 4-stelligen
> Postleitzahlen und welche mit 5 Stellen, bei denen die führende aber=
0
> ist. Wie unterscheidet man so etwas?

Ja, das ist ein Böser Fehler. Zeigt aber, das mein Programm keine User=
im=20
Bereich Dresden bis Karl-Marx-Stadt hat.=20

Ich könnte nach "real" casten und alles vor dem Komma verwerfen. Oder=
=20
nach "text". Bei letztere Lösung wären dann auch Vorsätze wi=
e "D-03532"=20
möglich.

Danke für den Hinweiß!

> > fax_oder_tel TEXT NOT NULL
>
> Was ist mit optionalen Handynummern, einer Sammelnummer und einer
> Durchwahl?

Ja, der Spatenname ist missverständlich. Man kann natürlich alles=
das darin=20
abkippen.

> > stellen_anzahl INTEGER
> > geschlecht TEXT
>
> Gibt es nur Stellen für Frauen XOR für Männer?

Bis vor garnicht so langer Zeit gab es tatsächlich Berufe die Frauen v=
erboten=20
wahren. Ich glaube es war Dachdecker und Schornsteinfeger. Aber es wird nic=
ht=20
mehr zum Maching verwendet. Nur als Ablage für den Manensvorsatz.

> > ALTER TABLE stelle RENAME COLUMN geschlecht TO salutation;
>
> "gender" wäre hier ev. besser passend, je nachdem welchen Zweck dies=
es
> Feld genau erfüllt.

"Dr, Prof., Med." usw.

> Ach, ich höre auf.

Trotzdem danke für den "Bugreport".

> > Ich will ja nicht ausschlissen, das wir was vergurkt haben, beim
> > Programmieren. Das Programm kommuniziert über die Lib npsql mit
> > PostgreSQL und die war/ist auch nicht Fehlerfrei. So gab es z.B. Proble=
me
> > mit dem Maskieren von Sonderzeichen (Funktionszeichen). Zu dem habe ich
> > die Entwicklerdatenbank unzählige male mit fehlerhaften Programmen=
oder
> > Tests zerschossen und immer wieder neu eingespielt. In den Letzten zwei
> > Jahren der Entwicklung habe ich das Programm auf meinen PC knapp 33.000
> > mal neu übersetzt und getestet. Es währe ein Wunder, wenn sic=
h da keine
> > Fehler eingeschlichen hätten. Die große Preisfrage lautet: wi=
e gehe ich
> > am besten damit um und wie kann ich sicherstellen, das alle nach dem
> > Upgrade die Gleichen Tabellenstruckturen haben?
>
> Du hast doch eine Tabelle mit Versionsnummern. Und du weisst
> hoffentlich noch, welche Änderungen sich von Version zu Version erge=
ben
> haben. Die spielst du nacheinander ein.

Das Problem ist, das jede Version ein "Update" und ein "Create". Wenn beide=
s=20
nicht das selbe Resultat liefern... Naja, der Rest ist klar. Wir haben 31=
=20
Versionen releaset. Nicht jede beinhaltete ein Update, aber so ein knappes=
=20
Dutzend könnte es schon gewesen sein. Wir müssten also alles 31 V=
ersionen=20
installieren...=20

> > Den Vorteil von Testdaten sehe ich darin, das man prüft, welche
> > Operationen alle gehen müssen und welche nicht gehen dürfen. =
Bei Fehlern
> > sucht man dann nach der Ursache, die vielerlei Gründe haben kann. =
Gut,
> > das mit einem Produktivsystem zu machen, ist wahrscheinlich nicht so ei=
ne
> > glorreiche Idee.
>
> Woher kannst du dir sicher sein deine Testdaten hinterher alle wieder
> aufzuräumen? Wenn du welche vergisst - wandern diese als
> Produktionsdaten in deine Datenbank.

Ja, so kommt dann so was zustande wie kürzlich bei der U.S. Army, wo t=
ausende=20
Hinterbliebene Anschreiben mit "Herr Musstermann" als Kondolenzschreiben=20=
=20
bekamen.=20

http://www.heise.de/newsticker/US-Army-verschickt-Max-Muster mann-Kondolenze=
n--/meldung/121360

> > Aber als Entwicklertool? Ein vorgeschlagener Weg, fängt das Proble=
m von
> > der anderen Seite an aufzurollen. Den Nachteil den ich sehe ist, das man
> > eigentlich das Problem schon kennen muss, um sinnvolle Tests zu machen.
> > Ansonsten gibt es einfach zufiel worauf man testen könnte.
>
> Das hört sich so an als ob nachträglich Tests eingeführt w=
erden, obwohl
> oder gerade weil der Versionsstand der Datenbank nicht bekannt ist?
>
> In dem Fall müsst ihr wohl wirklich einfach durch und die Probleme in
> Kauf nehmen.
>
>
> Bis dann
>
> --
> Andreas 'ads' Scherbaum
> German PostgreSQL User Group
> European PostgreSQL User Group - Board of Directors



--=20
Meine Rechtschreibfehler stehen unter der Creative Commons Lizenz.
(Bearbeitungen und Weitergabe unter gleichen Bedingungen):
http://creativecommons.org/licenses/by-sa/2.0/de/

--=20
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein