Hi!

Ich habe eine recht komplexe Tabellenstruktur. Um die Konsistenz sicher zu=

stellen, habe ich exzessiven Gebrauch von FOREIGN KEY gemacht. Jetzt kam ei=
n
Refactoring der DB und dutzende Tabellen und Spalten wurden umbenannt.
Seid dem ist die Konsistenz nicht mehr durch FOREIGN KEY gesch=C3=BCtzt. Ic=
h wei=C3=9F
nicht ob tats=C3=A4chlich das eine mit dem anderen zu tun hat. Ist nur eine=

Vermutung von mir. CONSTRAINTs sind noch da, aber ich kann wild alles l=C3=
=B6schen
ohne das mir die DB einhalt gebietet. Also: Wenn Tabellen und Spalten
umbenannt werden, gehen dabei dann die Verkn=C3=BCpfungen der FOREIGN KEY=

verloren?

Gru=C3=9F

Olaf

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

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

Olaf Radicke <briefkasten [at] olaf-radicke.de> schrieb:

> Hi!
>
> Ich habe eine recht komplexe Tabellenstruktur. Um die Konsistenz sicher=
zu
> stellen, habe ich exzessiven Gebrauch von FOREIGN KEY gemacht. Jetzt ka=
m ein
> 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
> Vermutung von mir. CONSTRAINTs sind noch da, aber ich kann wild alles l=
öschen
> ohne das mir die DB einhalt gebietet. Also: Wenn Tabellen und Spalten
> umbenannt werden, gehen dabei dann die Verknüpfungen der FOREIGN KEY
> 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!#





Andreas
--
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=B0, E 13.56889=
=B0

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

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
mit gpAdminIII die Tabellen angesehen. Und danach gab es einen FOREIGN KEY=

auf eine bestimmte Tabelle. Mein DB-Anwendung konnte aber ungestraft
Datensätze löschen.
Jetzt habe ich die DB noch mal mit psql untersucht und festgestellt das die=

FOREIGN KEY in einer anderen Tabelle existieren und funktionieren, nur in d=
em
einen Fall, sagte psql auf einmal es gäbe für die Tabelle kein FOREIGN =
KEY.
Als ich den händisch noch mal nachgebaut habe, konnte meine DB-Anwendung =
auch
nicht mehr herum wüten.
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.

Ich sitze jetzt in dem Dilemma, das ich jetzt nicht genau weiß, wie die=

aktuellen Tabellen meiner Anwender meiner Software aussehen. Mit jedem Upda=
te
wächst die Gefahr, das die Tabellen die durch eine Neuinstallation angele=
gt
werden, anders aussehen, als die, die den Update-Prozess durchlaufen haben.=

Durch das Refactoring wurde das Problem auch noch verschärft.

Vielleicht muss ich für den Upgrade einfach Test schreiben um herraus zu=

bekommen, ob die Tabellen so aussehen wie sie sollen. Also Dummy-Datensät=
ze
schreiben, lesen und löschen. Oh, mich grausts... Nur allein das
Refactoring-Upgrade hat schon 1500 Zeilen SQL.

MfG

Olaf


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

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

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=C3=A4ssig. So fragt mich das Tool jedesmal nach dem Passwort der D=
B und
> jedes mal fragt pgAdminIII ob es das Passwort speichern soll, und jedes m=
al
> 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=C3=9F, wie =
die
> aktuellen Tabellen meiner Anwender meiner Software aussehen. Mit jedem Up=
date
> w=C3=A4chst die Gefahr, das die Tabellen die durch eine Neuinstallation a=
ngelegt
> werden, anders aussehen, als die, die den Update-Prozess durchlaufen habe=
n.
> Durch das Refactoring wurde das Problem auch noch versch=C3=A4rft.

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=C3=B6rig faul. Wie genau schaut so ein Update bei euch
aus?



> Vielleicht muss ich f=C3=BCr den Upgrade einfach Test schreiben um herrau=
s zu
> bekommen, ob die Tabellen so aussehen wie sie sollen. Also Dummy-Datens=
=C3=A4tze
> schreiben, lesen und l=C3=B6schen. Oh, mich grausts... 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.

1500 Zeilen Update Code? H=C3=B6rt sich erst mal nicht wirklich viel an.


Bis dann

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

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

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=C3=A4ssig. 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=C3=9F, wi=
e die
> > aktuellen Tabellen meiner Anwender meiner Software aussehen. Mit jedem
> > Update w=C3=A4chst 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=C3=A4rft.
>
> 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=C3=B6rig 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=

ansehen k=C3=B6nnen.

Unter
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

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
Programmieren. Das Programm kommuniziert =C3=BCber die Lib npsql mit Postgr=
eSQL
und die war/ist auch nicht Fehlerfrei. So gab es z.B. Probleme mit dem
Maskieren von Sonderzeichen (Funktionszeichen). Zu dem habe ich die
Entwicklerdatenbank unz=C3=A4hlige male mit fehlerhaften Programmen oder Te=
sts
zerschossen und immer wieder neu eingespielt. In den Letzten zwei Jahren de=
r
Entwicklung habe ich das Programm auf meinen PC knapp 33.000 mal neu
=C3=BCbersetzt und getestet. Es w=C3=A4hre ein Wunder, wenn sich da keine F=
ehler
eingeschlichen h=C3=A4tten. Die gro=C3=9Fe Preisfrage lautet: wie gehe ich =
am besten
damit um und wie kann ich sicherstellen, das alle nach dem Upgrade die
Gleichen Tabellenstruckturen haben?

> > Vielleicht muss ich f=C3=BCr den Upgrade einfach Test schreiben um herr=
aus zu
> > bekommen, ob die Tabellen so aussehen wie sie sollen. Also
> > Dummy-Datens=C3=A4tze schreiben, lesen und l=C3=B6schen. 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=C3=BCft, welche Operat=
ionen
alle gehen m=C3=BCssen und welche nicht gehen d=C3=BCrfen. Bei Fehlern such=
t man dann
nach der Ursache, die vielerlei Gr=C3=BCnde haben kann. Gut, das mit einem=

Produktivsystem zu machen, ist wahrscheinlich nicht so eine glorreiche Idee=
..
Aber als Entwicklertool? Ein vorgeschlagener Weg, f=C3=A4ngt das Problem vo=
n 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=C3=B6nnte.

MfG

Olaf


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

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

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_upd=
ates/update_1.0.0.sql?view=3Dlog

Wenn es nur eine vorherige Version gibt, ist das doch ok. Ansonsten
br=C3=A4uchtest du Intermediate Skripts von jeder Version auf die n=C3=A4ch=
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=C3=BChren?


> 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=C3=BCrde wahrscheinlich ausreichen. Dazu fehlt ein CHECK auf die
m=C3=B6glichen Werte - oder ggf. doch ein ENUM.


> postleitzahl INTEGER NOT NULL

Das k=C3=B6nnte euch b=C3=B6se Probleme bereiten bei f=C3=BChrenden Nullen.
Das Land fehlt auch v=C3=B6llig. Es gibt L=C3=A4nder mit 4-stelligen
Postleitzahlen und welche mit 5 Stellen, bei denen die f=C3=BChrende 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=C3=BCr Frauen XOR f=C3=BCr M=C3=A4nner?


> ALTER TABLE stelle RENAME COLUMN geschlecht TO salutation;

"gender" w=C3=A4re hier ev. besser passend, je nachdem welchen Zweck dieses
Feld genau erf=C3=BCllt.


Ach, ich h=C3=B6re auf.





> Ich will ja nicht ausschlissen, das wir was vergurkt haben, beim
> Programmieren. Das Programm kommuniziert =C3=BCber die Lib npsql mit Post=
greSQL
> und die war/ist auch nicht Fehlerfrei. So gab es z.B. Probleme mit dem
> Maskieren von Sonderzeichen (Funktionszeichen). Zu dem habe ich die
> Entwicklerdatenbank unz=C3=A4hlige 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
> =C3=BCbersetzt und getestet. Es w=C3=A4hre ein Wunder, wenn sich da keine=
Fehler
> eingeschlichen h=C3=A4tten. Die gro=C3=9Fe Preisfrage lautet: wie gehe ic=
h 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 =C3=84nderungen sich von Version zu Version ergeben
haben. Die spielst du nacheinander ein.



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

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



> Aber als Entwicklertool? Ein vorgeschlagener Weg, f=C3=A4ngt das Problem =
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=C3=B6nnte.

Das h=C3=B6rt sich so an als ob nachtr=C3=A4glich Tests eingef=C3=BChrt wer=
den, obwohl
oder gerade weil der Versionsstand der Datenbank nicht bekannt ist?

In dem Fall m=C3=BCsst 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

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

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=C3=A4uchtest du Intermediate Skripts von jeder Version auf die n=C3=A4=
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
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=C3=B6de Beschr=C3=A4nkung in .Net-Runtime/Mono-Runtime. =
Eigentlich
h=C3=A4tte ich 1.1.01 haben m=C3=B6gen. Das verursacht aber ein Crash. V=C3=
=B6llig absurde
Geschichte. Das ist eigentlich ein Limit von MS-SQL und wurde verschleppt.=


> Wie kommt man denn auf die Idee, statt NULL ein veraltetes Datum
> einzuf=C3=BChren?

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

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=C3=BCrde wahrscheinlich ausreichen. Dazu fehlt ein CHECK auf die
> m=C3=B6glichen Werte - oder ggf. doch ein ENUM.

Die Spalte hat ihre Bedeutung ver=C3=A4ndert. Urspr=C3=BCnglich sollte mal =
ein "Maching"
dar=C3=BCber gemacht werden. Jetzt wird da nurnoch Namensvors=C3=A4tze abge=
kippt, ohne
weiter damit zu arbeiten. Da steht jetzt alles drinnen von "Herr", "Frau"=

bis "Oberstudienrat" und "General ad."

> > postleitzahl INTEGER NOT NULL
>
> Das k=C3=B6nnte euch b=C3=B6se Probleme bereiten bei f=C3=BChrenden Nulle=
n.
> Das Land fehlt auch v=C3=B6llig. Es gibt L=C3=A4nder mit 4-stelligen
> Postleitzahlen und welche mit 5 Stellen, bei denen die f=C3=BChrende aber=
0
> ist. Wie unterscheidet man so etwas?

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

Ich k=C3=B6nnte nach "real" casten und alles vor dem Komma verwerfen. Oder=

nach "text". Bei letztere L=C3=B6sung w=C3=A4ren dann auch Vors=C3=A4tze wi=
e "D-03532"
m=C3=B6glich.

Danke f=C3=BCr den Hinwei=C3=9F!

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

Ja, der Spatenname ist missverst=C3=A4ndlich. Man kann nat=C3=BCrlich alles=
das darin
abkippen.

> > stellen_anzahl INTEGER
> > geschlecht TEXT
>
> Gibt es nur Stellen f=C3=BCr Frauen XOR f=C3=BCr M=C3=A4nner?

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

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

"Dr, Prof., Med." usw.

> Ach, ich h=C3=B6re auf.

Trotzdem danke f=C3=BCr den "Bugreport".

> > Ich will ja nicht ausschlissen, das wir was vergurkt haben, beim
> > Programmieren. Das Programm kommuniziert =C3=BCber 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=C3=A4hlige 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 =C3=BCbersetzt und getestet. Es w=C3=A4hre ein Wunder, wenn sic=
h da keine
> > Fehler eingeschlichen h=C3=A4tten. Die gro=C3=9Fe 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 =C3=84nderungen 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
nicht das selbe Resultat liefern... Naja, der Rest ist klar. Wir haben 31=

Versionen releaset. Nicht jede beinhaltete ein Update, aber so ein knappes=

Dutzend k=C3=B6nnte es schon gewesen sein. Wir m=C3=BCssten also alles 31 V=
ersionen
installieren...

> > Den Vorteil von Testdaten sehe ich darin, das man pr=C3=BCft, welche
> > Operationen alle gehen m=C3=BCssen und welche nicht gehen d=C3=BCrfen. =
Bei Fehlern
> > sucht man dann nach der Ursache, die vielerlei Gr=C3=BCnde 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=C3=A4umen? Wenn du welche vergisst - wandern diese als
> Produktionsdaten in deine Datenbank.

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

bekamen.

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

> > Aber als Entwicklertool? Ein vorgeschlagener Weg, f=C3=A4ngt 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=C3=B6nnte.
>
> Das h=C3=B6rt sich so an als ob nachtr=C3=A4glich Tests eingef=C3=BChrt w=
erden, obwohl
> oder gerade weil der Versionsstand der Datenbank nicht bekannt ist?
>
> In dem Fall m=C3=BCsst 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



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

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