Can SQL Server Replication include the source dbid in the replicated data?

Question

Let's say I have DatabaseA with TableA, which has these fields: Id, Name.

In another database, DatabaseB, I have TableA which has these fields: DatabaseId, Id, Name.

Is it possible to setup a replication publication that will send:

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

to DatabaseB.TableA?

Edit: The reason I'm asking is that I need to combine multiple databases (with identical schemas) into a single database, with as little latency as possible. Replication seemed like a good place to start (need to replicate data from one place to another), but I'm just in the brainstorming phase. I would definitely be open to suggestions on how to accomplish this without using replication.

Answer 1

There might be an easier way to do it, but the first thing I thought of is wrapping TableA in an indexed view on the source database and then replicating the view as a table (i.e., type = "indexed view logbased"). I don't think this would work with merge replication, though.

So, that would roughly be like:

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',
    ...

Big caveat: indexed views have a lot of requirements that may not be appropriate for your application. For example, certain options have to be set any time you update the base table.

(In response to the edit in your question...) This won't work for combining multiple sources into one table. AFAIK, an object in a subscribing database can only come from one published article. And you can't do an indexed view on the subscribing side since UNION is not allowed in an indexed view. (The docs don't explicitly state UNION ALL is disallowed, but it wouldn't surprise me. You might try it just in case.) But it still does answer your explicit question: the dbid would be in the replicated table.

Answer 2

Are you aggregating these events in one place from multiple sources? Replicating only comes from one source - it's one-to-one, so the source ID doesn't seem like it would make much sense.

If you're aggregating data from multiple sources, maybe linked servers and triggers is a better choice, and if that's the case, then you could absolutely include any information about the source that you want.

If you can clarify your question to describe the purpose, it would help us find the best solution.

UPDATED FROM NEW DETAIL IN QUESTION:

Does this solution sound like it might be what you need?

1. Set up AFTER triggers on the source databases that send any changed rows to the central repository database, in some kind of holding table. These rows can include additional columns, like "Source", "Change type" (for insert, delete, etc).
2. Some central process watches the table and processes new rows (or runs periodically - once/minute, maybe), incorporating them into the central database

You could adjust how frequently the check/merge process runs on the server based on your needs (even running it constantly to handle new rows as they appear, perhaps even with an AFTER trigger on that table as well).