É uma boa ideia unir dados de dois bancos de dados diferentes?

1. Esta é uma prática padrão em empresas de nível empresarial?

Normalmente, os dados gerados nativamente de um aplicativo não abrangem vários bancos de dados, especialmente um aplicativo de nível empresarial, a menos que haja um caso de uso especial para isso. Por exemplo, alguns sistemas ERP (Enterprise Resource Planning) armazenam arquivos (como anexos em PDF) diretamente no banco de dados, em vez de em um compartilhamento de arquivos em disco. Como forma de mitigar a implosão do tamanho do banco de dados principal do aplicativo, eles armazenarão esses arquivos em um banco de dados especial separado. Armazenar arquivos no banco de dados geralmente é uma má escolha de design para começar, mas isso está além do objetivo da sua pergunta.

Não há nada de terrível em armazenar os dados entre vários bancos de dados, apenas não há muitos benefícios a serem obtidos com isso e há algumas desvantagens, além de ser um design um pouco estranho. Também existem soluções alternativas.

Desvantagens

1. A segurança entre bancos de dados pode ser um pouco difícil de gerenciar, dependendo das necessidades do negócio.
2. A integridade referencial sai um pouco da janela, já que uma chave estrangeira não pode ser criada em bancos de dados.
3. Os backups podem se tornar um pouco mais difíceis de gerenciar se o aplicativo depender de dados consistentes em vários bancos de dados.

Solução alternativa

Use esquemas dentro do mesmo banco de dados único como forma de organizar melhor os objetos de dados e também melhorar o gerenciamento de segurança em um nível mais granular. Os backups agora também são atômicos, já que tudo reside em um único banco de dados.

Os esquemas são uma ótima maneira de categorizar objetos de dados relacionados. Por exemplo, em um sistema ERP, pode haver módulos de aplicação e telas para Payroll, Production, e Sales. Na camada de banco de dados, cada um desses domínios poderia ser seu próprio esquema no mesmo banco de dados do aplicativo ERP. Então suas tabelas podem ser parecidas com Payroll.Employees, Payroll.Timecards, Production.Products, Production.Components, Sales.SalesOrders, Sales.SalesLines, e Sales.Customers, etc.

2. Como você normalmente junta dados de dois bancos de dados diferentes se é normal fazer isso?

Tudo o que foi dito acima, às vezes você terá um caso de uso para unir dados de vários bancos de dados de qualquer maneira, como quando você está reunindo dados de outros sistemas em um único local para serem referenciados em seu aplicativo. Quando for esse o caso, o que eu gosto de fazer primeiro é criar um esquema separado para cada banco de dados de origem, por exemplo SourceDatabaseA, SourceDatabaseB, etc, no banco de dados do meu aplicativo. Em seguida, crie visualizações nesses esquemas que fazem uma referência entre bancos de dados ao objeto do banco de dados de origem correlacionado.

Por exemplo:

-- This view makes a cross-database reference to the native source database
CREATE VIEW SourceDatabaseA.SomeDataObject
AS 

SELECT
    Field1,
    Field2,
    Field3
FROM SourceDatabaseA.dbo.SomeDataObject;

Isso fornece uma camada de abstração para normalizar os nomes e/ou tipos de dados do banco de dados de origem e injetar qualquer lógica global. Por fim, criarei um esquema que combine as diversas visualizações de origem, com um nome representativo do domínio ao qual esses objetos pertencem. Por exemplo, novamente, se eu estivesse extraindo os dados de vendas de bancos de dados de vários aplicativos, teria um Salesesquema e criaria uma visualização que une todas as fontes neste esquema da seguinte forma:

-- This view references only other data objects (views) that live in my application's database
CREATE VIEW Sales.SalesOrders
AS 

SELECT
    Field1,
    Field2,
    Field3
FROM SourceDatabaseA.SomeDataObject

UNION ALL

SELECT
    Field1,
    Field2,
    Field3
FROM SourceDatabaseB.SomeDataObject;

3. Isso causa problemas de latência?

Não, consultas entre bancos de dados ou objetos de dados que fazem referência a objetos entre bancos de dados não incorrem em nenhuma sobrecarga/latência mensurável adicional.

Depende do tipo de resultado que você deseja/espera.

essa ideia pode ser útil para obter insights ou relatórios gerais ou simplesmente para limpeza de dados.