Consentire alle applicazioni di condividere un database o mantenerle sincronizzate con i servizi Web?

Per farla breve: tutto in uno.

Se consideri uno di questi come "principale" e l'altro come una replica aumentata, gli aggiornamenti vengono replicati solo in un modo e puoi sopravvivere a grandi latenze durante la sincronizzazione (e ti consentirò di definire "grande") quindi funzioneranno due DB separati. Per qualsiasi altra cosa suggerirei un singolo DB.

Se hai aggiornamenti bidirezionali saranno sincroni o asincroni? Il primo e voi avete strettamente accoppiato i due DB. Quest'ultimo e devi avere misure di risoluzione dei conflitti in atto, aggiungendo complessità. Con un singolo DB hai l'intero weath della tecnologia della concorrenza per supportarti.

Con qualsiasi processo di copia ci sarà latenza, anche se è solo milli o micro-secondi. Questo è tutto ciò che serve per introdurre un'incoerenza tra i dati della fonte e quelli della replica, tuttavia, e quindi l'intera riconciliazione & cosa risoluzione ancora.

Come gestirai il DR? Come si garantisce un punto di sincronizzazione comune tra due DB, potenzialmente su server diversi (o centri dati)? Come ti assicuri di riavere i due nastri corrispondenti dal vault esterno prima volta, ogni volta?

Qualsiasi modifica dello schema che aggiunge tabelle o colonne sarà trasparente per l'altra applicazione. (Non stai scrivendo SELECT * , sei? SEI?) Rimuovere gli oggetti dovrebbe riguardare solo i moduli che usano poi, che vorresti comunque modificare. (Due DB con una tabella ridondante in una ma rimossi dall'altra odori come una potenziale fonte di grande confusione per me). Cambiare lo schema perché le regole aziendali sono cambiate può causare una duplicazione del lavoro; ma mi sembra che un'applicazione non stia implementando quella regola aziendale che non ha alcuna chiamata per essere in quella parte del DB comunque.

È possibile archiviare i file di codice di implementazione ORM in modo da renderli comuni a entrambe le applicazioni? Quindi le modifiche dello schema avranno effetto solo su un set di codice.

"Database come singolo punto di errore". Bene, giusto punto. Ma poi è stato su assolutamente ogni applicazione che abbia mai lavorato dal momento che hanno tutti avuto un DB. Ecco perché abbiamo cluster / mirror / alta disponibilità integrati nei prodotti DBMS. Se hai due DB e uno fallisce, allora? Ritorno al ciclo di riconciliazione / risoluzione dei conflitti. È anche un singolo punto di messa a punto; sistemalo in un posto ed è fisso ovunque!

Avrei pensato che le viste, le stored procedure, l'ORM stesso e la limitazione degli elementi in qualsiasi query SELECT sarebbero state in grado di isolare qualsiasi parte dell'applicazione dai dati in cui non ha alcun interesse.

La mia lettura della tua domanda è che le tue due applicazioni sono in realtà abbastanza strettamente accoppiate. La mia risposta è colorata da quello. Ho scritto molti sistemi in cui copia in massa o dati di replica a due vie e ne gestisco le conseguenze.

Ero abituato a lavorare su un'applicazione simile, ma la situazione prevista nella mia applicazione sarebbe molto diversa da come funzionerebbe questo sito, Facebook, Twitter o la tua applicazione.

Questo è solo nel caso, questo può darti un po 'di intuizione. Inserisco sia i dati di autenticazione che i dati aziendali nello stesso database SQL. I motivi sono:

1. Quando l'applicazione diventa abbastanza grande da non bastare un singolo server, i fornitori SQL aziendali forniscono sempre una soluzione cluster che astrae il modo in cui il DB funziona in modo distribuito. Non dovresti preoccuparti di un singolo punto di errore o di prestazioni scadenti.
2. Lo schema deve essere stabile, se vuoi assicurarti che le cose funzionino anche quando cambi lo schema dei dati. Stai chiedendo troppo.
3. Avere entrambi nello stesso servizio SQL server ti risparmia tutti i mal di testa che devi affrontare con modifiche simultanee nel diritto di accesso dell'utente. Pensa a qualcuno che modifica i valori di controllo degli accessi per un utente quando una richiesta da quell'utente arriva al servizio back-end.

Si noti che nella mia applicazione, mi aspetto un piccolo numero di utenti e un'enorme quantità di dati. Non nel modo in cui questo sito web, o Facebook, o Twitter, o persino la tua applicazione quando il numero di utenti è enorme (anche se confrontato con i dati aziendali)

Qualcosa da considerare potrebbe essere un approccio di Master Data Management (MDM). Esso consisterebbe fondamentalmente in un archivio dati operativo per ogni applicazione, ognuno dei quali utilizza un lavoro ETL o una replica per sincronizzarsi con un archivio dati principale.

Ogni schema di archiviazione dei dati operativi può evolversi indipendentemente, con il lavoro ETL che gestisce tutte le traduzioni necessarie. Ogni quanto tempo sincronizzi e in quale direzione (s) dipenderà dalle vostre esigenze.

Questo modello è spesso utilizzato negli scenari di data warehousing, ma può anche funzionare per i dati transazionali. Metterai le tue applicazioni oi tuoi servizi web di fronte agli archivi di dati operativi, e forse i rapporti o altri servizi a valle potrebbero consumare dall'archivio dati principale se lo desideri.

Sono disponibili diverse soluzioni MDM commerciali che possono fornire:

• funzionalità aggiuntive
• flessibilità architettonica
• sicurezza
• integrità dei dati
• scalabilità

Tuttavia, questo modello può anche essere implementato senza una soluzione o strumento commerciale MDM. I database sarebbero designati come operativi e master e sarebbe necessario creare i necessari processi di replica per spostare i dati tra di loro.

Qualunque sia l'implementazione specifica, questo modello può aiutare a scindere i due schemi operativi l'uno dall'altro.