Can replicação SQL Server incluem o dbid fonte nos dados replicados?

Question

Digamos que eu tenho DatabaseA com TableA, que tem esses campos:. Id, nome

Em outro banco de dados, DatabaseB, tenho TableA que tem estes campos: DatabaseID, identificação, nome

.

É possível configurar uma publicação de replicação que irá enviar:

DatabaseA.dbid, DatabaseA.TableA.Id, DatabaseA.TableA.Name

para DatabaseB.TableA?

Edit: A razão que eu estou pedindo é que eu preciso combinar vários bancos de dados (com esquemas idênticos) em um único banco de dados, com o mínimo de latência possível. Replicação parecia um bom lugar para começar (necessidade de dados replicados de um lugar para outro), mas eu sou apenas na fase de brainstorming. Eu definitivamente estar aberto a sugestões sobre como fazer isso sem o uso de replicação.

Answer 1

Pode haver uma maneira mais fácil de fazê-lo, mas a primeira coisa que pensei é TableA embrulho em uma exibição indexada na base de dados de origem e, em seguida, replicando a vista como uma tabela (ou seja, type = "exibição indexada logbased") . Eu não acho que isso iria trabalhar com replicação de mesclagem, no entanto.

Então, isso seria mais ou menos ser como:

CREATE VIEW TableA_with_dbid WITH SCHEMABINDING AS
SELECT DatabaseA.dbid, Id, Name FROM TableA

CREATE UNIQUE CLUSTERED INDEX ON TableA_with_dbid (Id) -- or whatever your PK is

EXEC sp_addarticle ...,
    @source_object = 'TableA_with_dbid',
    @destination_table = 'TableA',
    @type = 'indexed view logbased',
    ...

grande limitação: indexados vistas têm um monte de requisitos que pode não ser apropriado para a sua aplicação. Por exemplo, certas opções têm de ser definido qualquer momento que você atualizar a tabela base.

(Em resposta ao editar na sua pergunta ...) Isso não vai funcionar para combinar várias fontes em uma tabela. AFAIK, um objeto em um banco de dados de subscrição só pode vir de um artigo publicado. E você não pode fazer uma exibição indexada no lado assinando desde UNION não é permitido em uma exibição indexada. (Os documentos não declarar explicitamente UNION ALL não é permitido, mas não me surpreenderia Você pode experimentá-lo apenas no caso..) Mas ainda não responder a sua pergunta explícita:. O dbid estaria na tabela replicada

Answer 2

Você está agregando esses eventos em um só lugar a partir de múltiplas fontes? Replicando só vem de uma fonte -. É um-para-um, de modo que o ID de origem não parece que ele faria muito sentido

Se você está agregando dados de várias fontes, servidores talvez ligados e triggers é uma escolha melhor, e se esse for o caso, então você absolutamente poderia incluir qualquer informação sobre a fonte que você deseja.

Se você pode esclarecer sua pergunta para descrever a finalidade, seria nos ajudar a encontrar a melhor solução.

atualizado de novo detalhe em questão:

Isso soa solução como ele poderia ser o que você precisa?

1. , criado após os gatilhos das bases de dados de origem que enviam quaisquer linhas alteradas no banco de dados repositório central, em algum tipo de segura a mesa. Essas linhas podem incluir colunas adicionais, como "Source", "Change Tipo" (para inserir, excluir, etc).
2. Alguns processo central relógios tabela e processa novas linhas (ou executa periodicamente - uma vez / minuto, talvez), incorporando-os na base de dados central

Você pode ajustar a freqüência com que a verificação / processo de mesclagem é executado no servidor com base em suas necessidades (até mesmo executá-lo constantemente para lidar com novas linhas como eles aparecem, talvez até com um gatilho AFTER naquela mesa bem).