Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Организация репликации  [new]
Newb_Replicator
Guest
Всем доброго вечера!

Осваиваю репликацию на практике, прошу не пинать сильно. Опишу требования:
1. Один центральный сервер с sql2005 standard edition.
2. Сеть филиалов (порядка 70-80) с sql2005 express edition.

Архитектура достаточно стандартная. На центральном сервере ведется в основном аналитика и подтверждаются счета на оплату из филиалов.

Требуется
1. Односторонняя репликация справочников из центра в филиалы. Справочники ведутся только в центральном офисе.
2. Данные забиваются в филиалах и периодически реплицируются в центр.

Вроде бы тут подходит тип репликации merge, но, поскольку обмен двусторонний, предвижу проблемы. В частности не получится ли так, что через некоторое время в каждом филиале-1 появятся данные из филиала-2 и всех прочих? Возможно отменить репликацию в сторону подписчика?
19 ноя 09, 17:15    [7952555]     Ответить | Цитировать Сообщить модератору
 Re: Организация репликации  [new]
Glory
Member

Откуда:
Сообщений: 104760
Newb_Replicator


Вроде бы тут подходит тип репликации merge, но, поскольку обмен двусторонний, предвижу проблемы. В частности не получится ли так, что через некоторое время в каждом филиале-1 появятся данные из филиала-2 и всех прочих? Возможно отменить репликацию в сторону подписчика?

BOL - Filtering Published Data
19 ноя 09, 17:20    [7952596]     Ответить | Цитировать Сообщить модератору
 Re: Организация репликации  [new]
Newb_Replicator
Guest
Glory
Newb_Replicator


Вроде бы тут подходит тип репликации merge, но, поскольку обмен двусторонний, предвижу проблемы. В частности не получится ли так, что через некоторое время в каждом филиале-1 появятся данные из филиала-2 и всех прочих? Возможно отменить репликацию в сторону подписчика?

BOL - Filtering Published Data
Ага, спасибо!

Еще вопрос по этой же теме. Посоветуйте как лучше решить такую задачку. Данные заносимые в филиалах - это в том числе и персональные данные. Идентификацию личности решено делать по следующим признакам: ФИО, дата рождения, номер паспорта, номер документа. Ок. Но одна и та же персона может прийти в несколько филиалов и ее занесут дважды и более. Надо слить копии персон в одну.

Есть ли среди стандартных средств репликации средства для такого слияния? Я лично вижу такие решения:
1. Натуральные первичные ключи (этот вариант мне нравится менее всего).
2. В промежуточную БД сливаем все данные из филиалов, а потом итоговою БД для аналитики переносим запросами "своего разлива".

Какой вариант более удобен? Или есть еще какой способ?
19 ноя 09, 17:35    [7952674]     Ответить | Цитировать Сообщить модератору
 Re: Организация репликации  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74927
Вы бы определились, сначала, с архитектурой:

автор
Справочники ведутся только в центральном офисе.

...
автор
Но одна и та же персона может прийти в несколько филиалов и ее занесут дважды и более. Надо слить копии персон в одну.
19 ноя 09, 17:39    [7952703]     Ответить | Цитировать Сообщить модератору
 Re: Организация репликации  [new]
Newb_Replicator
Guest
pkarklin
Вы бы определились, сначала, с архитектурой:

автор
Справочники ведутся только в центральном офисе.

...
автор
Но одна и та же персона может прийти в несколько филиалов и ее занесут дважды и более. Надо слить копии персон в одну.
Определился я с архитектурой. Таблицы делятся на две группы: реплицируемые только со стороны центра в филиалы и реплицируемые в направлении центра.
19 ноя 09, 17:47    [7952746]     Ответить | Цитировать Сообщить модератору
 Re: Организация репликации  [new]
Glory
Member

Откуда:
Сообщений: 104760
Newb_Replicator
pkarklin
Вы бы определились, сначала, с архитектурой:

автор
Справочники ведутся только в центральном офисе.

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

И в какую группу попала таблица "Клиенты" ?
19 ноя 09, 17:52    [7952768]     Ответить | Цитировать Сообщить модератору
 Re: Организация репликации  [new]
Newb_Replicator
Guest
Glory
Newb_Replicator
pkarklin
Вы бы определились, сначала, с архитектурой:

автор
Справочники ведутся только в центральном офисе.

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

И в какую группу попала таблица "Клиенты" ?
Клиенты попадают во вторую группу, т.е. их заносят в филиалах. В центре ведется вся НСИ (это первая группа) + крутится несложная аналитика по итогам данных, принятых из филиалов.
19 ноя 09, 17:55    [7952782]     Ответить | Цитировать Сообщить модератору
 Re: Организация репликации  [new]
Glory
Member

Откуда:
Сообщений: 104760
Newb_Replicator

И в какую группу попала таблица "Клиенты" ?
Клиенты попадают во вторую группу, т.е. их заносят в филиалах. В центре ведется вся НСИ (это первая группа) + крутится несложная аналитика по итогам данных, принятых из филиалов.[/quot]
И как проверяется, что клиент этот уже есть в других филиалах/центральном сервере ?
19 ноя 09, 17:56    [7952792]     Ответить | Цитировать Сообщить модератору
 Re: Организация репликации  [new]
Newb_Replicator
Guest
Glory
И как проверяется, что клиент этот уже есть в других филиалах/центральном сервере ?
Никак не проверяется. Клиент уникален (по установленным критериям) в пределах БД филиала. Но если наложить условие уникальности декларативно в БД издателя, то ессесьно, получим облом при репликации. Отсюда и вопрос: как лучше обойти этот затык?
19 ноя 09, 18:09    [7952845]     Ответить | Цитировать Сообщить модератору
 Re: Организация репликации  [new]
Glory
Member

Откуда:
Сообщений: 104760
Newb_Replicator
Glory
И как проверяется, что клиент этот уже есть в других филиалах/центральном сервере ?
Никак не проверяется. Клиент уникален (по установленным критериям) в пределах БД филиала. Но если наложить условие уникальности декларативно в БД издателя, то ессесьно, получим облом при репликации. Отсюда и вопрос: как лучше обойти этот затык?

Давать клиенту уникальный глобальный суррогатный ключ ?
19 ноя 09, 18:11    [7952863]     Ответить | Цитировать Сообщить модератору
 Re: Организация репликации  [new]
Newb_Replicator
Guest
Newb_Replicator
Glory
И как проверяется, что клиент этот уже есть в других филиалах/центральном сервере ?
Никак не проверяется. Клиент уникален (по установленным критериям) в пределах БД филиала. Но если наложить условие уникальности декларативно в БД издателя, то ессесьно, получим облом при репликации. Отсюда и вопрос: как лучше обойти этот затык?
Поправлюсь. Клиент уникален (по установленным критериям) в пределах БД филиала, но в итоге он должен оказаться уникальным и в БД центра, используемой для аналитических отчетов. Последняя совсем не обязательно должна совпадать с публикуемой БД.
Glory
Давать клиенту уникальный глобальный суррогатный ключ ?
Это суровая и очевидная необходимость, поскольку иначе не пройдет репликация, это придется делать в любом случае. Как? Это вопрос. Есть вариант с диапазонами первичных ключей. Старый, проверенный способ. Или гуид в качестве PK.

Но в отчетах дублей персон быть не должно. И лучше (для той же производительности запросов), чтобы от них избавиться не только в выборках, но и в таблицах. Я склоняюсь к решению с использованием с промежуточной БД, из которой данные переливать в конечную базу для аналитики. Я думаю кто-то встречался с такой задачей и может поделиться соображениями.
19 ноя 09, 20:22    [7953270]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить