Re: disable trigger ALL

Patryk Kordylewski <pk(at)fooby(dot)de> wrote:

> Hey Andreas,

Hi Patryk, schön, daß Du Dir die Zeit nimmst, ...

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

Yeah!

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

Ja, jetzt wo ich auch mit etwas weniger Blutdruck drüber nachdenke
sollte es keine katastrophalen Nebenwirkungen haben.

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

Yepp. Falls z.B. die Statistiken dann für'n A.... sind, nun ja, kommen
halt (vielleicht) dumme Pläne raus, aber nicht wirklich ein Problem ;-)

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

Du kennst das ja sicher: Termindruck.

Ich find's halt Schade, diese Umstellung wäre DER Zeitpunkt für eine
Datenbereinigung gewesen...

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

Yeah, das ist ihm bekannt, das nimmt er 'in Kauf'.

Das ist halt so der Punkt, der mich ärgert: er hat nun die Chance auf
ein richtig rund laufendes System, und verbaut es sich so. Dumm.

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

Wenn jemand versucht, die Trigger zu aktivieren, wird er einen Fehler
bekommen und sich gezwungen sehen, ein ROLLBACK zu machen, mehr sollte
einklich nicht passieren.

Aber Danke für den Hinweis auf pg_restore - ich schau mir morgen mal den
Dump an. Wenn das VOR dem Einspielen der Daten drin steht, sollte ja
alles okay sein.

>
> Gruß,
> Patryk

Thx, Grüße an Deine Schlangen und Lisa ;-)
(Oh mein Gott, nicht falsch verstehen ...)

>
> 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 (pgsql-de-allgemein(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-de-allgemein

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°