Skip site navigation (1) Skip section navigation (2)

Re: FOREIGN KEY

From: Olaf Radicke <briefkasten(at)olaf-radicke(dot)de>
To: pgsql-de-allgemein(at)postgresql(dot)org
Subject: Re: FOREIGN KEY
Date: 2009-01-26 23:42:08
Message-ID: 200901270042.08740.briefkasten@olaf-radicke.de (view raw or flat)
Thread:
Lists: 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_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/

In response to

pgsql-de-allgemein by date

Next:From: Frank MöbiusDate: 2009-01-28 14:23:12
Subject: WAL-Archivierung - pg_dumpall
Previous:From: Andreas 'ads' ScherbaumDate: 2009-01-26 22:21:21
Subject: == Wöchentlicher PostgreSQL Newsletter - 25. Januar 2009 ==

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group