Penso che quello che stai cercando sia Oracle Data Base Links.

CREA IL LINK DEL DATABASE

Use the CREATE DATABASE LINK statement to create a database link. A database link is a schema object in one database that enables you to access objects on another database. The other database need not be an Oracle Database system.

Tutti i prodotti RDBMS che mi vengono in mente hanno una funzione per collegare database e query su più database. Se questo è l'unico requisito che hai e non puoi prevedere altri requisiti per l'interrogazione cross-database, personalmente non mi affretto a collegare i database per fare ciò. Considererei tutti i potenziali aspetti negativi e penso attentamente. Sarei preoccupato di introdurre un impatto sulle prestazioni dal momento che i database non si trovano nella stessa posizione e potenzialmente potrebbero rendere il prodotto più difficile da supportare. Quest'ultimo dipenderà dal modo in cui è strutturata la tua organizzazione IT e dagli standard / pratiche stabiliti dagli amministratori di database.

Se non si scende il percorso del database collegato per questo requisito, avviarei thread in background in parallelo ognuno dei quali si connette e interroga ogni DB remoto per dati simili.

Stabilire la connessione a ciascun DB è un'operazione abbastanza costosa. Se la tua app si collega già a ciascuna periodicamente, il pool di database potrebbe essere d'aiuto in quanto il pool di DB manterrebbe le connessioni aperte e disponibili.

Un'altra cosa da considerare è che sembra che la tua app non sia proprietaria dei database e dei dati. Ovviamente, qualunque percorso tu faccia per collegarti al database di back-end di questa altra app proprietaria, potresti dipendere dall'altra app per non trasformare il suo modello di dati in un modo che rompe il tuo.

La tua applicazione è l'unico punto di aggiornamento in tutti i database? In caso contrario, avrai comunque un sacco di problemi con il dup.

D'altra parte, se la tua app è il singolo punto di aggiornamento, allora potresti usare una cache centralizzata usando NoSQL e usarla come cache write-through, prima di salvare gli aggiornamenti nei vari database in modo tale che tu possa solo è necessario interrogare quella cache per verificare la presenza di duplicati.

C'è un'alternativa ai thread.

Il caso d'uso che spieghi non sembra aver bisogno di essere sincrono.

Quindi potresti creare uno script che legge un database e scrive su una tabella temporanea. Tale script riceverà le informazioni di connessione tramite i parametri passati ad esso. In questo modo puoi pianificare cron jobs con gli stessi script ma diversi database che vengono eseguiti in parallelo in un dato momento.

Un secondo lavoro eseguirà il polling per vedere se quei lavori sono terminati e quindi eseguirà il confronto e memorizzerà i risultati in una tabella a punto singolo.

Il modulo di immissione dei dati potrebbe invece controllare con quelle tabelle pre-elaborate e, se i dati sono troppo vecchi (configurabili), dire all'utente di attendere una notifica in un'area di notifica per dare loro un senso di flusso di lavoro.

È solo una possibile alternativa.

Inoltre, se il modulo di immissione mostra all'utente un elenco a discesa di nomi esistenti, è possibile salvare il tempo di conferma dell'utente.