La réplication SQL Server peut-elle inclure le dbid source dans les données répliquées?

Question

Disons que j'ai DatabaseA avec TableA, qui contient les champs suivants: Id, Nom.

Dans une autre base de données, DatabaseB, j'ai TableA qui contient les champs suivants: DatabaseId, Id, Name.

Est-il possible de configurer une publication de réplication qui enverra:

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

vers DatabaseB.TableA?

Modifier: La raison pour laquelle je pose cette question est que je dois associer plusieurs bases de données (avec des schémas identiques) en une seule base de données, avec le moins de latence possible. La réplication semblait être un bon point de départ (nécessité de répliquer les données d'un endroit à un autre), mais je suis juste en phase de brainstorming. Je serais certainement ouvert aux suggestions sur la façon de réaliser cela sans utiliser la réplication.

Answer 1

Il existe peut-être un moyen plus simple de le faire, mais la première chose à laquelle je pensais était de placer TableA dans une vue indexée de la base de données source, puis de la répliquer sous forme de table (c'est-à-dire, type = "indexé dans la vue indexée"). ). Je ne pense pas que cela fonctionnerait avec la réplication de fusion, cependant.

Donc, ce serait à peu près comme:

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

Attention importante: les vues indexées ont de nombreuses exigences qui peut ne pas être approprié pour votre application. Par exemple, certaines options doivent être définies chaque fois que vous mettez à jour la table de base.

(En réponse à la modification de votre question ...) Cela ne fonctionnera pas pour combiner plusieurs sources dans une seule table. Autant que je sache, un objet dans une base de données d'abonnement ne peut provenir que d'un seul article publié. Et vous ne pouvez pas créer de vue indexée du côté abonné, car UNION n'est pas autorisé dans une vue indexée. (Les documents n'indiquent pas explicitement que UNION ALL n'est pas autorisé, mais cela ne me surprendrait pas. Vous pourriez l'essayer juste au cas où.) Mais cela répond toujours à votre question explicite: le dbid serait dans la table répliquée.

Answer 2

Réunissez-vous ces événements en un seul endroit à partir de plusieurs sources? La réplication ne provient que d'une seule source. Elle est personnalisée. L'identifiant de la source ne semble donc pas très logique.

Si vous regroupez des données provenant de plusieurs sources, des serveurs et des déclencheurs liés sont peut-être un meilleur choix. Si tel est le cas, vous pouvez absolument inclure toute information sur la source souhaitée.

Si vous pouviez préciser votre question afin de décrire l'objectif, cela nous aiderait à trouver la meilleure solution.

À JOUR DU NOUVEAU DÉTAIL EN QUESTION:

Cette solution vous semble-t-elle être ce dont vous avez besoin?

1. Configurez les déclencheurs AFTER sur les bases de données source qui envoient les lignes modifiées à la base de données du référentiel central, dans une sorte de table de rétention. Ces lignes peuvent inclure des colonnes supplémentaires, telles que "Source", "Modifier le type". (pour insérer, supprimer, etc.).
2. Certains processus centraux surveillent la table et traitent les nouvelles lignes (ou les exécutent périodiquement - une fois par minute, peut-être), en les incorporant à la base de données centrale

Vous pouvez ajuster la fréquence à laquelle le processus de vérification / fusion s'exécute sur le serveur en fonction de vos besoins (même en l'exécutant en permanence pour gérer les nouvelles lignes telles qu'elles apparaissent, peut-être même avec un déclencheur AFTER sur cette table également).