É uma boa ideia usar o Sinônimos para evitar a criação de uma tabela duplicada?

Temos 3 cópias do mesmo banco de dados. Todos os 3 bancos de dados têm uma Userstabela, e um Usuário sempre existirá em todos os 3 bancos de dados com exatamente as mesmas configurações. Sempre que quisermos adicionar ou editar um Usuário, precisamos atualizar 3 bancos de dados.

Seria uma idéia melhor excluir a Userstabela dos bancos de dados 2 e 3 e substituí-la por uma Synonymque aponte para o banco de dados 1?

Aqui estão os prós / contras em que consigo pensar:

Prós

• Manutenção mais fácil. Pode atualizar usuários em um local em vez de 3
• Os IDs de usuário corresponderiam aos bancos de dados (Importante, pois muitos aplicativos complementares são baseados no UserId)

Contras

• Não pense que este é um procedimento padrão, por isso pode ser confuso
• Os usuários precisariam ter configurações idênticas entre os bancos de dados
• (Da resposta de gbn abaixo) Se o Banco de Dados 1 for desativado, os bancos de dados 2 e 3 também estarão indisponíveis. Também existe o possível problema de os dados serem inconsistentes no caso de uma restauração

Esta é uma opção que estou considerando para algumas tabelas diferentes que contêm configurações idênticas entre os bancos de dados, não apenas a Userstabela. Estou usando Usuários no exemplo, pois é fácil de entender.

Por que você tem 3 bancos de dados com os mesmos usuários?

O que acontece se um banco de dados ficar inativo agora?

Estou fazendo essas perguntas porque o golpe do banco de dados de origem do usuário diminuindo, impedindo o uso dos outros dois bancos de dados, pode não ser tão grande quanto parece.

Além disso, se um banco de dados ficar inativo agora, você já terá problemas de consistência se os usuários forem modificados nos outros dois bancos de dados durante esse período. Acho que não podemos dar os melhores conselhos sem mais contexto.

No momento, eu criaria um quarto banco de dados para usuários, faria alterações apenas lá e sincronizaria com os outros bancos de dados. Você já está distribuído, não normalizado, alterando essencialmente os mesmos dados em três locais e provavelmente já tem problemas de consistência. Se a tolerância a falhas é importante, esse esquema ainda fornece isso ao resolver o problema de entradas múltiplas.

Eu acho que ter esse quarto banco de dados somente de usuário / configurações, em vez de usar um dos já existentes, é uma boa estratégia, pois é menos provável que ocorra, pois não está vinculado a outros recursos ou é muito usado. Vejo agora que você disse que não pode fazer isso, mas não sei por que. Os aplicativos no banco de dados principal suportam a edição do usuário diretamente ou a edição do usuário é uma função completamente separada que pode ser apontada em outro lugar?

É verdade que, com essa idéia da "tabela de usuário canônica" - seja você usar sinônimos ou sincronizar os dados - você não pode modificar usuários durante um banco de dados inativo, mas isso me parece aceitável. Corrija o problema e traga-o à tona! Uma fonte, um lugar para editar, uma coisa para corrigir, se quebrada. Com a sincronização, todos os outros bancos de dados têm cópias temporárias das quais podem trabalhar, mas sem edição. Minimizar a duplicação de dados nos sistemas é um objetivo excelente e útil. É um problema sério inserir os mesmos dados em três locais; faça o que puder para eliminar isso.

Para tratar mais de seus comentários, se seus IDs de usuário forem diferentes em todos os seus aplicativos, considere seriamente um tempo de inatividade planejado para que seus dois novos bancos de dados os sincronizem com o principal (faça uma pergunta separada se precisar de ideias sobre como fazer isso, o que é complicado, mas não tão difícil assim).

Se você analisar as necessidades da sua empresa e achar que o banco de dados principal deve ter os dados do usuário, você ainda os usa como canônico e, em seguida, escolha entre sinônimos ou sincronização para resolver como os períodos de inatividade não planejados afetam todos os bancos de dados.

Um golpe adicional ao uso de sinônimos é que você não seria mais capaz de ter FKs adequados para os usuários em cada banco de dados.

Há um "Con" ausente

Na restauração, é possível que seu usuário não exista no banco de dados de destino (do sinônimo). Digamos que ele esteja corrompido e você precise restaurar a partir de um backup.

Ou seja, o uso de sinônimos assumirá integridade referencial entre bancos de dados, o que não pode acontecer na vida real.

Outra consequência disso seria userids incompatíveis quando você tentar se recuperar disso. (adicionando o usuário após a restauração). No entanto, isso nunca deve ser assumido de qualquer maneira devido à integridade referencial entre bancos de dados que mencionei.

Então, não faça isso ...

Uma resposta relacionada no dba.se: Critérios de decisão sobre quando usar um esquema não dbo versus um novo banco de dados sobre "integridade referencial entre bancos de dados" após restaurações

Dependendo da plataforma do banco de dados, outra opção é excluir as tabelas nos bancos de dados 2 e 3 e substituí-las por visualizações materializadas da tabela no banco de dados 1.

Prós

• Manutenção mais fácil (dos dados)
• IDs correspondentes
• Interrupções não afetam outros bancos de dados (pelo menos até que sejam necessárias alterações)
• Qualquer banco de dados pode ser usado para recuperar a tabela.

Contras

• Os dados são tão atualizados quanto sua programação de atualização.
• Se a definição da tabela mudar, as visualizações materializadas também poderão precisar ser alteradas.

Observe também que, dependendo da frequência das pesquisas, da frequência das atualizações e da frequência dos dados alterados, isso pode ou não introduzir mais carga que uma solução sinônima.

Atualização: o comentário de FrustratedWithFormsDesigner é essencialmente uma Visualização materializada para plataformas que não podem realizar visualizações materializadas. Usando um script, as tabelas podem ser sincronizadas periodicamente. Se um banco de dados for designado como mestre, todos os scripts poderão fazer suas alterações com base nele. Isso teria todos os prós e contras de uma visão materializada; simplesmente não podia tirar proveito da funcionalidade incorporada.

Eu criaria um quarto banco de dados que armazena as informações do usuário compartilhadas. Crie Synonymsou Viewsem cada um dos outros Dbs apontando para o banco de dados usuários.

Por fim, eu criaria uma tabela de extensão (uma tabela com um relacionamento individual com o 'UserDB.Usertable') em cada um dos 3 dbs existentes que contém dados do usuário específicos desse aplicativo.

Editar: Com base no comentário abaixo

Nesse caso, faça com que o primeiro banco de dados aja como a tabela de usuário mestre. Synonymse uma tabela de extensão em cada um dos outros Dbs.

Nota importante : Com essa abordagem, se o seu primeiro aplicativo for desativado, os outros dois serão pressionados! Certifique-se de que todos entendam essa desvantagem.