[Gfoss] Errore nel backUp di postgres

[G. Allegri]

Non credo si possa dire a priori qual'è la strada 'corretta'. Dipende,
ovviamente, dalle specifiche del prodotto.
Io in genere propongo ai clienti il seguente approccio:

 - carico tutti i dati in uno stato "raw"
 - facio una serie di controlli sulla bontà del dato
 - quelli buoni li committo, gli altri li tengo in stato "pending", e
poi valuto col cliente (o chi dovrà comunque usufruire del dato) il da
farsi. Talvolta il pending viene scartato, talvolta viene accettato ma
annotando eventuali problemi nei metadati.

giovanni

Il 09 settembre 2010 14:57, Paolo Corti <pcorti a gmail.com> ha scritto:
>
> 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