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:
>
> 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_updates/update_1.0.0.sql?view=log

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.

Ein paar Anmerkungen zu dem Skript vielleicht noch:

> UPDATE mitglied SET geburtsdatum = 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 = '' 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.

> 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. Probleme 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 sich da keine Fehler
> eingeschlichen hätten. Die große Preisfrage lautet: wie 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 ergeben
haben. Die spielst du nacheinander ein.

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

> Aber als Entwicklertool? Ein vorgeschlagener Weg, fängt 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önnte.

Das hört sich so an als ob nachträglich Tests eingeführt werden, 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