Может ли SQL Server Replication включать исходный dbid в реплицированные данные? - PullRequest
Новая
       13

Может ли SQL Server Replication включать исходный dbid в реплицированные данные?

2 голосов
/ 07 января 2009

Допустим, у меня есть DatabaseA с таблицей A, в которой есть следующие поля: Id, Name.

В другой базе данных, DatabaseB, у меня есть таблица A, в которой есть следующие поля: DatabaseId, Id, Name.

Можно ли настроить публикацию репликации, которая будет отправлять:

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

в базу данныхB.TableA?

Edit: Причина, по которой я спрашиваю, состоит в том, что мне нужно объединить несколько баз данных (с одинаковыми схемами) в одну базу данных с минимально возможной задержкой. Репликация казалась хорошим местом для начала (нужно реплицировать данные из одного места в другое), но я только на этапе мозгового штурма. Я определенно был бы открыт для предложений о том, как сделать это без использования репликации.

Ответы [ 2 ]

2 голосов
/ 07 января 2009

Возможно, существует более простой способ сделать это, но первое, о чем я подумал, - это обернуть TableA в индексированное представление исходной базы данных и затем реплицировать представление в виде таблицы (то есть type = "indexed view logbased") , Но я не думаю, что это сработает с репликацией слиянием.

Итак, это примерно так: 

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

Большое предостережение: индексированные представления имеют множество требований , которые могут не подходить для вашего приложения. Например, определенные параметры должны быть установлены каждый раз, когда вы обновляете базовую таблицу.

(В ответ на редактирование в вашем вопросе ...) Это не будет работать для объединения нескольких источников в одну таблицу. AFAIK, объект в подписной базе данных может быть взят только из одной опубликованной статьи. И вы не можете сделать индексированное представление на стороне подписки, так как UNION не допускается в индексированном представлении. (В документах не указано, что UNION ALL запрещен, но меня это не удивит. Вы можете попробовать это на всякий случай.) Но он все равно отвечает на ваш явный вопрос: dbid будет в реплицированной таблице.

2 голосов
/ 07 января 2009

Собираете ли вы эти события в одном месте из нескольких источников? Репликация идет только из одного источника - это один-к-одному, поэтому идентификатор источника, похоже, не имеет большого смысла.

Если вы агрегируете данные из нескольких источников, возможно, лучше использовать связанные серверы и триггеры, и если это так, то вы можете абсолютно точно включить любую информацию об источнике, который вам нужен.

Если вы сможете уточнить свой вопрос и описать цель, это поможет нам найти лучшее решение.

ОБНОВЛЕНО ИЗ НОВОЙ ДЕТАЛИ ВОПРОС:

Похоже ли это решение на то, что вам нужно?

  1. Настройте триггеры AFTER в исходных базах данных, которые отправляют любые измененные строки в центральную базу данных репозитория, в каком-то виде таблицы хранения. Эти строки могут включать дополнительные столбцы, такие как «Источник», «Изменить тип» (для вставки, удаления и т. Д.).
  2. Некоторый центральный процесс просматривает таблицу и обрабатывает новые строки (или запускается периодически - возможно, раз в минуту), включая их в центральную базу данных

Вы можете настроить частоту выполнения процесса проверки / слияния на сервере в соответствии с вашими потребностями (даже запускать его постоянно для обработки новых строк по мере их появления, возможно, даже с использованием триггера AFTER для этой таблицы).

...