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_upd
> >ates/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.

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

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

Das ist eine saublöde Beschränkung in .Net-Runtime/Mono-Runtime. Eigentlich
hätte ich 1.1.01 haben mögen. Das verursacht aber ein Crash. Völlig 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ühren?

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

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

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

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

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

Ich könnte nach "real" casten und alles vor dem Komma verwerfen. Oder
nach "text". Bei letztere Lösung wären dann auch Vorsätze wie "D-03532"
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
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 verboten
wahren. Ich glaube es war Dachdecker und Schornsteinfeger. Aber es wird nicht
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 dieses
> 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. 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.

Das Problem ist, das jede Version ein "Update" und ein "Create". Wenn beides
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önnte es schon gewesen sein. Wir müssten also alles 31 Versionen
installieren...

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

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

http://www.heise.de/newsticker/US-Army-verschickt-Max-Mustermann-Kondolenzen--/meldung/121360

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

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