SQL Server Replication può includere il dbid di origine nei dati replicati?

Question

Diciamo che ho DatabaseA con TableA, che ha questi campi: Id, Nome.

In un altro database, DatabaseB, ho TableA che ha questi campi: DatabaseId, Id, Name.

È possibile impostare una pubblicazione di replica che invierà:

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

su DatabaseB.TableA?

Modifica: Il motivo per cui mi chiedo è che devo combinare più database (con schemi identici) in un unico database, con la minor latenza possibile. La replica sembrava un buon punto di partenza (è necessario replicare i dati da un luogo all'altro), ma sono solo nella fase di brainstorming. Sarei sicuramente aperto a suggerimenti su come ottenere questo risultato senza utilizzare la replica.

Answer 1

Potrebbe esserci un modo più semplice per farlo, ma la prima cosa che ho pensato è racchiudere TableA in una vista indicizzata sul database di origine e quindi replicare la vista come una tabella (ovvero, tipo = " vista indicizzata basata su log " ). Tuttavia, non penso che funzionerebbe con la replica di tipo merge.

Quindi, sarebbe approssimativamente come:

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 avvertenza: le visualizzazioni indicizzate hanno molti requisiti che potrebbe non essere appropriato per la tua applicazione. Ad esempio, alcune opzioni devono essere impostate ogni volta che si aggiorna la tabella di base.

(In risposta alla modifica nella tua domanda ...) Questo non funzionerà per combinare più fonti in una tabella. AFAIK, un oggetto in un database di abbonamento può provenire solo da un articolo pubblicato. E non è possibile eseguire una vista indicizzata sul lato della sottoscrizione poiché UNION non è consentito in una vista indicizzata. (I documenti non dichiarano esplicitamente che UNION ALL è vietato, ma non mi sorprenderebbe. Potresti provarlo per ogni evenienza.) Ma continua a rispondere alla tua domanda esplicita: il dbid sarebbe nella tabella replicata.

Answer 2

Stai aggregando questi eventi in un unico posto da più fonti? La replica proviene solo da una fonte: è una a una, quindi l'ID sorgente non sembra avere molto senso.

Se stai aggregando dati da più fonti, forse i server e i trigger collegati sono una scelta migliore, e in tal caso, potresti assolutamente includere qualsiasi informazione sulla fonte che desideri.

Se puoi chiarire la tua domanda per descrivere lo scopo, ci aiuterebbe a trovare la soluzione migliore.

AGGIORNATO DAL NUOVO DETTAGLIO IN DOMANDA:

Questa soluzione sembra che potrebbe essere ciò di cui hai bisogno?

1. Imposta i trigger AFTER sui database di origine che inviano eventuali righe modificate al database del repository centrale, in una sorta di tabella di mantenimento. Queste righe possono includere colonne aggiuntive, come " Sorgente " ;, " Cambia tipo " (per inserire, eliminare, ecc.)
2. Alcuni processi centrali controllano la tabella ed elaborano nuove righe (o vengono eseguite periodicamente - una volta / minuto, forse), incorporandole nel database centrale

È possibile regolare la frequenza con cui il processo di verifica / unione viene eseguito sul server in base alle proprie esigenze (anche eseguendolo costantemente per gestire le nuove righe così come appaiono, forse anche con un trigger AFTER su quella tabella).