Re: disable trigger ALL

Hey Andreas,

erstmal Glückwunsch das der Kunde sich entschlossen hat auf PG zu
wechseln, man sieht ja was er bisher versäumt hat und in welchem Chaos
er jetzt steckt.

Zu deinen Fragen, Performance Probleme sollte er nicht bekommen, da die
Constraints nix mit Indices zu tun haben - die sind ja weiterhin
vorhanden und werden bei JOINs, usw. verwendet. Datenverlust sollte er
auch nicht erleiden.

PG wird bei deaktivierten Constraint-Triggern natürlich die Constraints
nicht prüfen, somit bleibt der Schrott in der Datenbank - und ich
vermute da die Anwendung jetzt schon nicht meckert, wird die Anwendung
auch weiterhin Datenschrott erzeugen. Ob über Constraint-Trigger noch
weitere interne Funktionen abgedeckt werden (Aktualisierung von
Statistiken oder sowas?) weiss ich nicht. Und ob davon auch andere
Constraints (Unique, Checks, usw.) betroffen ist leider auch nicht,
müsste man mal nachlesen/testen. Im schlimmsten/besten Fall verbaut er
sich alle möglichen Features zur Prüfung von Daten.

Was ich nicht verstehe ist wieso man die Daten nicht bereinigt - es kann
ja nicht so schwer sein im einfachsten Fall ein paar Spalten in ein paar
Tabellen auf NULL zu setzen. Wenn es mehr ist kann man das sogar
automatisieren (information_schema + pl/pgsql + EXECUTE hilft).

Ein Problem welches er aber haben könnte ist das er sich die komplette
Trigger-Funktionalität verbaut - da DISABLE TRIGGER ALL auch die
USER-Trigger beinhaltet wird er keine manuellen/normalen Trigger anlegen
können. Könnte aber sein das ihn das nicht interessiert weil Doctrine
hier eigene Möglichkeiten bietet Events abzubilden.

Zusätzlich könnte natürlich jemand irgendwann ausversehen die Trigger
wieder aktivieren (wie sich pg_restore hier verhält weiss ich grad nicht
genau).

Gruß,
Patryk

On 18.12.2013 18:43, Andreas Kretschmer wrote:
> 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
>