È una buona idea usare sinonimi per evitare di creare una tabella duplicata?

Abbiamo 3 copie dello stesso database esatto. Tutti e 3 i database hanno una Userstabella e un utente esisterà sempre in tutti e 3 i database con le stesse impostazioni esatte. Ogni volta che vogliamo aggiungere o modificare un utente, dobbiamo aggiornare 3 database.

Sarebbe una buona idea eliminare la Userstabella dai database 2 e 3 e sostituirla con una Synonymche punti al database 1?

Ecco i pro / contro che mi vengono in mente:

Professionisti

• Manutenzione più semplice. Può aggiornare gli utenti in una posizione anziché 3
• Gli ID utente corrisponderebbero tra i database (importante poiché molte app aggiuntive si basano su UserId)

Contro

• Non pensare che questa sia una procedura standard, quindi potrebbe essere fonte di confusione
• Gli utenti dovrebbero avere impostazioni identiche tra i database
• (Dalla risposta di gbn di seguito) Se il Database 1 dovesse mai andare in fumo, anche i Database 2 e 3 non saranno disponibili. Inoltre, esiste il potenziale problema che i dati risultino incoerenti in caso di ripristino

Questa è un'opzione che sto prendendo in considerazione per alcune diverse tabelle contenenti impostazioni identiche tra i database, non solo la Userstabella. Sto usando gli utenti nell'esempio poiché è facile da capire.

Perché hai 3 database con gli stessi utenti?

Cosa succede se un database si arresta adesso?

Sto ponendo queste domande perché il Con del database di origine utente che va in giù impedendo l'uso degli altri due database potrebbe non essere un problema così grande come sembra.

Inoltre, se un database si arresta ora, si avranno già problemi di coerenza se gli utenti vengono modificati negli altri due DB durante quel periodo. Non credo che possiamo dare il miglior consiglio senza più contesto.

In questo momento vorrei creare un quarto database per gli utenti, apportare modifiche solo lì e sincronizzarmi con gli altri database. Sei già distribuito-denormalizzato modificando essenzialmente gli stessi dati in tre punti e probabilmente hai già problemi di coerenza. Se la tolleranza agli errori è importante, questo schema lo fornisce ancora durante la risoluzione del problema di inserimento multiplo.

Penso che avere questo quarto database solo per utenti / impostazioni piuttosto che utilizzare uno dei tuoi database esistenti sia una buona strategia in quanto diventa meno probabile che vada giù poiché non è legato ad altre risorse o utilizzato pesantemente. Vedo ora che hai detto che non puoi farlo, ma non sono chiaro sul perché. Le applicazioni sul database principale supportano direttamente la modifica dell'utente o la modifica dell'utente è una funzione completamente separata che può essere indirizzata altrove?

È vero, con questa idea di "tabella utenti canonica", sia che si utilizzino sinonimi o si sincronizzino i dati, non è possibile modificare gli utenti durante un DB utente discendente, ma a me sembra giusto. Risolvi il problema e risolvilo! Una fonte, un posto da modificare, una cosa da riparare se rotta. Con la sincronizzazione, tutti gli altri database hanno copie temporanee da cui possono lavorare, ma nessuna modifica. Ridurre al minimo la duplicazione dei dati tra i sistemi è un obiettivo grande e utile. È un problema serio inserire gli stessi dati in tre punti, quindi fai tutto il possibile per eliminarli.

Per rispondere a più dei tuoi commenti, se i tuoi ID utente sono diversi in tutte le tue applicazioni, allora dovresti considerare seriamente un tempo di inattività pianificato per i tuoi due nuovi database per metterli in sincronia con quello principale (fai una domanda separata se hai bisogno di idee su come realizzare questo, che è difficile ma non è così difficile).

Se analizzi le tue esigenze aziendali e scopri che il database principale deve avere i dati dell'utente che vanno bene, lo usi comunque come canonico, quindi scegli tra sinonimi o sincronizzazione per affrontare l'impatto dei tempi di inattività non pianificati su tutti i database.

Un ulteriore svantaggio dell'uso dei sinonimi è che non si sarebbe più in grado di avere FK appropriati per gli utenti in ciascun database.

Manca un "Con"

Al ripristino, è possibile che l'utente non esista nel database di destinazione (del sinonimo). Dì che è danneggiato e devi ripristinare da un backup.

Cioè, l'uso di sinonimi assumerà integrità referenziale tra database che non può accadere nella vita reale.

Un'altra conseguenza di ciò sarebbe userid non corrispondenti quando si tenta di recuperare da questo. (aggiungendo l'utente dopo il ripristino). Tuttavia, ciò non dovrebbe mai essere assunto a causa dell'integrità referenziale tra database che ho menzionato.

Quindi, non farlo ...

Una risposta correlata su dba.se: criteri di decisione su quando utilizzare uno schema non dbo rispetto a un nuovo database sull'integrità referenziale tra database dopo i ripristini

A seconda della piattaforma del database, un'altra opzione è eliminare le tabelle nei database 2 e 3 e sostituirle con viste materializzate della tabella nel database 1.

Professionisti

• Manutenzione più semplice (dei dati)
• ID corrispondenti
• Le interruzioni non influiscono su altri database (almeno fino a quando non è necessario apportare modifiche)
• È possibile utilizzare qualsiasi database per ripristinare la tabella.

Contro

• I dati sono aggiornati solo come il programma di aggiornamento.
• Se la definizione della tabella cambia, potrebbe essere necessario modificare anche le viste materializzate.

Si noti inoltre che, a seconda della frequenza delle ricerche, della frequenza degli aggiornamenti e della frequenza della modifica dei dati, ciò può o meno introdurre più carico di una soluzione sinonimo.

Aggiornamento: il commento di FrustratedWithFormsDesigner è essenzialmente una vista materializzata per piattaforme che non possono eseguire viste materializzate. Utilizzando uno script, le tabelle potrebbero essere periodicamente sincronizzate. Se un database è designato come master, tutti gli script potrebbero apportare le modifiche in base ad esso. Ciò avrebbe tutti i pro e i contro di una visione materializzata; semplicemente non poteva sfruttare la funzionalità integrata.

Vorrei creare un quarto DB che memorizza le informazioni utente condivise. Creare Synonymso Viewsin ciascuno degli altri DBS che puntano al DB degli utenti.

Infine, creerei una tabella di estensioni (una tabella con una relazione One-one con "UserDB.Usertable") in ognuna delle 3 dbs esistenti che contengono i dati dell'utente specifici dell'app.

Modifica: in base al commento qui sotto

In tal caso, fare in modo che il primo db funga da tabella utente principale. Synonymse una tabella di estensione in ciascuno degli altri Dbs.

Nota importante : con questo approccio, se la tua prima app si interrompe, le altre due vengono abbattute con essa! Assicurati che tutti comprendano questo inconveniente.