[Gfoss] Errore nel backUp di postgres

[Paolo Corti]

Sent from mobile

On 09/set/2010, at 13:10, Andrea Peri <aperi2007 a gmail.com> wrote:

Va bene i trigger, ma l'azione non puo' essere il non caricare il record.

Prova a immaginare cosa vuol dire che una feature non viene "storata"
perche'
la sua componente geometrica non e' valida.

se quella feature aveva una FK verso altre tabelle e cosi' via a cascata,
altri records non verranno storati.
Poi ti ritrovi con dei buchi nella tua copertura, che magari deve essere a
totale copertura del suolo e i buchi non sono ammissibili.
E questo solo perche' vi era un fiocchettino con una area di 10 cm ?

Cavolo !

Per un problema che dal punto di vista della geometria e' molto
probabilmente sotto il limite di validita' dei dati presenti nella copertura
mi si introduce una grana grossa come una montagna record mancanti, vincoli
violati, etc...

La soluzione non puo' essere questa, ma bensi' storare nel DB comunque, poi
si effettua una select che controlla se vi e' qualcosa di non valido e se
presente ci si passa sopra qualcosa che risolve il problema o al limite si
corregge a mano, ma non si puo' cancellare il record.
Cosi' vi e' il rischio concreto che spariscano case, solo perche' avevano un
fiocchetto microscopico nella loro geometria.


Non sono affatto d'accordo.
Uno dei grossi vantaggi di un db relazionale e' quello di poter gestire
l'integrità referenziale dei dati a differenza di formati dati flat.
Eliminare fk, costanti, vincoli ecc ecc al fine di poter comunque caricare i
dati per poi correggerli e renderli validi e' una cosa che a mio avviso
nella maggior parte delle situazioni, con db in produzione, non ci si può
permettere.
Tali operazioni vanno fatte nelle procedure di caricamento, manuali o
automatiche che siano
Poi ognuno la può pensare diversamente eh ;)
Ciao
P
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.faunalia.it/pipermail/gfoss/attachments/20100909/9b60ccc0/attachment-0001.htm>