disable trigger ALL

select *,


ein Kunde von uns stellt nun mal endlich von seiner fürchterlichen MySQL
4.x - Lösung (*würg*) auf PG um. Soweit - so gut.
(fragt nicht nach weiteren Details der bisherigen Lösung...)

Er macht via Doctrine ein Redesign der Tabellen, das Schema sieht auch
nett aus, mit vielen schönen FK-Beziehungen und so.

Beim Import der Daten merkt er aber, daß die Daten komplett inkonsistent
sind und die FK-Constraints fröhlich vor sich hin eskalieren...
Ist ja auch nicht verwunderlich - kommen aus MySQL.


Ein Droppen der Constraints wollte er nicht, weil Doctrine z.B. bei
Schemaänderungen die wohl wieder einbauen würde - er hatte eine
'bessere' Lösung: siehe $SUBJECT, und das dauerhaft.


Mal von der Tatsache abgesehen, daß ich gar nicht wußte, daß man so
FK-Constraints umgehen kann: welche Argumente könnte ich dem Kunden noch
bringen, daß diese Idee ganz grober Unfug ist?

Drohen hier Dinge wie Datenverlust und/oder falsche Resultate und/oder
Performanceprobleme? Wie wird sich PG verhalten, verläßt es sich auf
sein Wissen zu FK-Constraints oder, aufgrund der abgeschalteten Trigger,
behandelt der die Daten als das, was sie sind: Schrott? 

Er hat zwar unterschrieben, daß wir für keinerlei Folgen uns haftbar
fühlen, aber was meint ihr dazu? Ich find's einfach nur Schade...



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°, E 13.56889°


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