Un modo per risolvere questo problema consiste nel creare una vista materializzata della tabella principale sul database locale, quindi creare il vincolo di integrità che punta alla MV.
Che funziona. Ma può portare ad alcuni problemi. Innanzitutto, se è necessario eseguire un aggiornamento completo della vista materializzata, è necessario disabilitare il vincolo prima di farlo. In caso contrario, Oracle non sarà in grado di eliminare le righe nella MV prima di inserire le nuove righe.
In secondo luogo, è possibile che si verifichino dei ritardi temporali. Ad esempio, supponi di aggiungere un record alla tabella principale sul sito remoto. Quindi si desidera aggiungere un record figlio alla tabella locale. Ma la MV è impostata per aggiornare quotidianamente e ciò non è ancora avvenuto. Otterrai una violazione di chiave esterna, semplicemente perché la MV non è stata aggiornata.
Se si segue questa rotta, l'approccio più sicuro consiste nell'impostare la MV su un aggiornamento rapido al commit della tabella master. Ciò significa mantenere aperto un DB Link quasi tutto il tempo. E avrai del lavoro da fare se hai bisogno di fare un aggiornamento completo.
Tutto sommato, abbiamo generalmente riscontrato che un trigger è più semplice. In alcuni casi, abbiamo semplicemente definito l'FK nel nostro modello logico, ma l'abbiamo implementato manualmente impostando un lavoro giornaliero che verificherà le violazioni e il personale di avviso. Certo, siamo abbastanza attenti, quindi quegli avvisi sono estremamente rari.
fonte
2010-06-04 13:27:39
E tenere a mente qualsiasi backup/ripristino di entrambi i database potrebbe interrompere questo 'vincolo'. –