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 17:33:07
Message-ID: 200901261833.08196.briefkasten@olaf-radicke.de (view raw or flat)
Thread:
Lists: 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ä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ß, wie die
> > aktuellen Tabellen meiner Anwender meiner Software aussehen. Mit jedem
> > Update wächst die Gefahr, das die Tabellen die durch eine Neuinstallation
> > 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=182673&package_id=241269
Als LiveCD mit "sudo su" und "su postgres" wirst du dir die DB detailliert 
ansehen können.

Unter 
http://sourceforge.net/project/showfiles.php?group_id=182673&package_id=307319

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

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? 

> > 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ätze schreiben, lesen und löschen. 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.

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

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/

In response to

Responses

pgsql-de-allgemein by date

Next:From: Andreas 'ads' ScherbaumDate: 2009-01-26 20:59:00
Subject: Re: FOREIGN KEY
Previous:From: Andreas 'ads' ScherbaumDate: 2009-01-26 11:46:09
Subject: Re: FOREIGN KEY

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