Ter relações entre bancos de dados separados é uma má prática?

Estou trabalhando com um cliente que possui vários bancos de dados. Existem vários masterbancos de dados de nível que têm relacionamentos com eles a partir de instancebancos de dados de nível (DBs específicos do aplicativo). Os relacionamentos de instancepara mastersão valores inteiros que representam uma chave primária para tabelas no master. As visualizações e procedimentos armazenados em instancessão configurados para carregar dados a masterpartir dessas chaves armazenadas.

Obviamente, não há integridade referencial real, mas isso é uma prática ruim ou os dados devem residir em tabelas somente leitura nos instancebancos de dados?

A única questão é que não há realmente uma maneira conveniente de reforçar esses relacionamentos. Você pode usar um monte de gatilhos ou armazenar a tabela mestre em cada banco de dados de instância e simplesmente expor todos eles como metadados ao mestre, talvez usando uma visualização.

A maior desvantagem, eu acho, tem a ver com manter os dados precisos e sincronizados, em pelo menos três cenários que estão na minha cabeça (todos os quais ainda podem ser um problema, mesmo se você usar gatilhos):

• transações entre bancos de dados coordenadas incorretamente - por exemplo, uma transação adiciona uma nova linha ao mestre, transfere a identidade para outra transação e, em seguida, a primeira transação é revertida.
• recuperação de uma única falha no banco de dados - um banco de dados trava, é necessário restaurar para um ponto no tempo, que pode ter ocorrido antes da conclusão de outras transações bem-sucedidas em outros bancos de dados. Isso pode significar que, se um banco de dados da instância precisar reverter para um período anterior, faltam linhas que o mestre espera; se o mestre precisar reverter, é possível que todos os bancos de dados da instância tenham valores que não existem no mestre.
• consistência do backup em geral - se você precisar de recuperação de desastres, será difícil manter todos os backups completos e de log transacionalmente consistentes até certo ponto. As capturas instantâneas do sistema de arquivos não ajudam nisso, e mesmo os Grupos de Disponibilidade não garantem consistência transacional entre bancos de dados para os bancos de dados em um único Grupo de Disponibilidade. Se você tiver um desastre e precisar restaurar seus bancos de dados para um novo sistema, não há como garantir que eles sejam transacionalmente consistentes.

Dito isso, sempre fui e sempre serei fã de separar os inquilinos em seus próprios bancos de dados e reconheço que há risco associado ao banco de dados central - mas é necessário.

(Como um aparte, você deve usar nomes para seus bancos de dados que não sejam mestre / instância. masterNo SQL Server definitivamente tem um significado explícito, e até mesmo ler minhas próprias palavras acima pode ser ambígua. O mesmo para instance. Em uma vida anterior, executei vários -antant system e chamamos o banco de dados central Controle os bancos de dados de inquilinos, bem Tenants.)

Se você está seguindo uma arquitetura como a Microservices, é praticamente necessário correlacionar dados entre vários serviços autônomos, cada um com seu próprio armazenamento de dados. Será entendido por cada serviço que os processos de negócios que tradicionalmente seriam executados em uma única transação de banco de dados agora podem ser potencialmente mais demorados.