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°