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
>


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