Il modo migliore per sincronizzare i dati da un database a un altro

Question

Il modo migliore per sincronizzare i dati da un database a un altro

#1 da (2 voti)
#2 da (0 voti)

0

Diciamo che il mio negozio web e il mio database hanno più tabelle come Prodotti, Prezzi dei prodotti e simili. Sto vendendo la mia soluzione software al mio partner affiliato. Ottiene il suo database, la finestra dell'applicazione per inserire i dati e voglio che tutti i suoi prodotti siano disponibili anche sul mio sito. Quindi, ho i miei prodotti e li vendo sul mio sito web. Il partner ha il suo sito Web e i suoi prodotti, ma voglio anche che tutti i suoi prodotti siano disponibili anche nel mio database. La mia idea iniziale era quella di creare una sorta di app che si collegasse periodicamente al database del partner e inserisca / aggiorni i dati nelle mie tabelle. Ma recentemente penso ad alcuni autobus di servizio. L'autobus di servizio è la strada da percorrere? Quindi la situazione sarebbe come questa. Il partner inserisce il prodotto (il bus invia il messaggio che i prodotti sono stati inseriti, i prezzi degli aggiornamenti dei partner, quindi il bus invia un messaggio che la riga di una riga dei prezzi è stata modificata. Avrei quindi un'applicazione per console in esecuzione sul server che ascolta il messaggio e gli aggiornamenti al mio database. pensi che sarebbe una soluzione scalabile? L'esempio è immaginario e nella vita reale ho molte tabelle.

database-development service-bus

posta Vlado Pandžić 31.05.2017 - 21:03

fonte

2 risposte

Leggi altre domande sui tag database-development service-bus

Modi generici per aggregare e presentare i dati Asp.Net Mvc 5 / Web Api 2 per testare il livello di accesso ai dati

score 2 · Answer 1

Per prima cosa è necessario porsi alcune domande:

hai bisogno di sincronizzare i dati in tempo reale, quasi in tempo reale o in una sorta di modalità di backup (come una volta al giorno).
quando si spostano i dati lo si manipola o si replica completamente in un altro database (forse di qualche tempo).
qual è la quantità di dati per, ad esempio minuto? Sono 1000 record o 100000 record? Ci sono delle relazioni nel db che devono essere replicate sull'altro lato? O forse l'altra estremità è senza schemi, quindi non ti interessa?
Qual è la tecnologia su entrambi i lati? Ad esempio, MS SQL sever ha funzionalità di replica integrate, almeno 3 opzioni come ricordo.
C'è qualche problema con la connessione tra la prima e la seconda archiviazione? Sono nella stessa rete, forse nella stessa organizzazione? O forse sono in 2 reti diverse collegate VPN.
In che modo contrassegni i record che sono stati replicati?
Come scoprirai che i record sono stati aggiornati e devono essere nuovamente sostituiti (trigger? - ma possono aggiungerli a ogni tabella)?

Ogni risposta può essere decisiva. Anche nel 2017 possiamo ancora trovare la sincronizzazione tramite file FTP, a causa di motivi non tecnici.

Applicazione console? Solo se eseguito periodicamente da Windows Scheduler, non usarlo mai come servizio permanente - questo è ciò che sono per i servizi di windows deamons / windows. Bus di servizio: sembra fantastico, come sempre, ma ancora una volta, se è necessario replicare db con un sacco di relazioni, potrebbe rivelarsi, si sta tirando mezzo database per ogni oggetto trasferito. Spero che questo ti aiuti a scegliere una soluzione, Łukasz

score 0 · Answer 2

Stai gestendo il database per il tuo partner? In caso contrario, non credo che ti dia accesso al loro database sia una buona idea (problemi di sicurezza). Un'altra cosa: probabilmente vuoi che i tuoi prodotti siano separati da quelli dei tuoi partner.

In ogni caso, il bus di servizio è parte della soluzione, proprio come un gestore di messaggi. Quindi quello che ti serve è questo:

Qualcosa per inviare prodotti nuovi e aggiornati dalla tua parte del partner alla tua (che può benissimo essere un lavoro che invia messaggi a un bus di servizio).
Qualcosa per ascoltare la coda dei messaggi e afferrare i prodotti e inserirli nel tuo database nel modulo che ti piace.

La scalabilità dipende dalla tua piattaforma. Ma anche per piccole soluzioni on-premise, questo sembra molto piccolo e in grado di funzionare con una quantità ragionevole di dati (niente dimensioni di Amazon).