Avere relazioni tra database separati è una cattiva pratica?

Sto lavorando con un client che ha più database. Esistono diversi masterdatabase di livello che hanno relazioni con essi da instancedatabase di livello (DB specifici dell'applicazione). Le relazioni da instancea mastersono valori interi che rappresentano una chiave primaria per le tabelle in master. Le viste e le procedure memorizzate nel instancessono configurate per caricare i dati da masterqueste chiavi memorizzate.

Ovviamente, non esiste una reale integrità referenziale, ma è una cattiva pratica o i dati dovrebbero risiedere in tabelle di sola lettura nei instancedatabase?

L'unico problema è che non esiste davvero un modo conveniente per far rispettare queste relazioni. È possibile utilizzare un carico di trigger di barche o archiviare la tabella principale in ciascun database di istanza ed esporli semplicemente come metadati al master, utilizzando forse una vista.

Il rovescio della medaglia più grande, penso, ha a che fare con il mantenimento dei dati precisi e sincronizzati, in almeno tre scenari fuori dalla mia testa (tutti i quali possono ancora essere un problema anche se si utilizzano i trigger):

• Transazioni incrociate tra database erroneamente coordinate : ad esempio una transazione aggiunge una nuova riga al master, passa l'identità a un'altra transazione e quindi la prima transazione esegue il rollback.
• ripristino da un singolo errore del database : un database si arresta in modo anomalo, è necessario ripristinarlo fino a un certo momento, che potrebbe essere stato prima del completamento di altre transazioni riuscite in altri database. Ciò potrebbe significare che se un database di istanze deve tornare a una volta precedente, mancano le righe che il master si aspetta; se il master deve ripristinare, è possibile che tutti i database dell'istanza abbiano valori che non esistono nel master.
• coerenza del backup in generale : se è necessario il ripristino di emergenza, sarà difficile mantenere tutti i backup completi e i log di transazione in modo transazionale fino a un certo momento. Le snapshot del file system non sono di aiuto in questo, e persino i gruppi di disponibilità non garantiscono la coerenza transazionale tra database per i database in un singolo gruppo di disponibilità. Se hai un disastro e devi ripristinare i tuoi database su un nuovo sistema, non c'è modo di essere sicuri che siano coerenti a livello transazionale.

Detto questo, sono sempre stato e sarò sempre un fan della separazione degli inquilini nei loro database, e riconosco che esiste un rischio associato al database centrale, ma è necessario.

(A parte, dovresti usare nomi per i tuoi database diversi da master / istanza. masterIn SQL Server ha sicuramente un significato esplicito e anche leggere le mie parole sopra potrebbero essere ambigui. Lo stesso per instance. In una vita precedente ho eseguito un multi -tenant system e abbiamo chiamato il database centrale Controle i database dei tenant, beh Tenants.)

Se stai seguendo un'architettura come Microservices, è praticamente necessario essere in grado di correlare i dati tra più servizi autonomi, ognuno con il proprio archivio dati. Ogni servizio comprenderà che i processi aziendali che tradizionalmente verrebbero eseguiti in una singola transazione di database ora potrebbero essere potenzialmente più lunghi.