Конференция VBStreets

**NRJ** » 26.01.2006 (Чт) 17:51

Есть несколько подразделений одной конторы разбросанных на большие расстояния. Необходимо ведение баз данных на местах и централизация данных в одном месте. Главная база на MS SQL Server на местах MS Access. Способы передачи: "привезли на дискете", с помощью интернет. Базы однородны у всех.
После слияния баз в центральном офисе возможно редактирование данных, при следующем слиянии той же базы изменённые записи должны быть заменены в источнике.
Основной вопрос: "Как производить процессы репликации (слияния)"

**alibek** » 26.01.2006 (Чт) 18:10

Нужна репликация в обе стороны (от филиалов в центр и от центра в филиалы) или только в одну?
Для каждой записи хранить дату последнего изменения (дата и время) и счетчик изменений (целое). Ну и при слиянии ориентироваться на эти значения.

**Sebas** » 27.01.2006 (Пт) 9:47

alibek писал(а):Нужна репликация в обе стороны (от филиалов в центр и от центра в филиалы) или только в одну?
Для каждой записи хранить дату последнего изменения (дата и время) и счетчик изменений (целое). Ну и при слиянии ориентироваться на эти значения.

+ ещё поле статуса записи (удалена-изменена-нормуль)

Но это..... гиблое дело...

Мой совет: по возможности не связывайся с распределёнными базами!
Здоровье дороже!

**NRJ** » 27.01.2006 (Пт) 10:04

alibek писал(а):Нужна репликация в обе стороны (от филиалов в центр и от центра в филиалы) или только в одну?
Для каждой записи хранить дату последнего изменения (дата и время) и счетчик изменений (целое). Ну и при слиянии ориентироваться на эти значения.

Основной перенос данных из филиала в центр. Но в центре эти данные могут быть подправлены, при следующей репликации этогоже филиала в филиале должны быть сделаны соответствующие изменения.
1) привезли базу - слили уехали. мы отредактировали.
2) приехали в следующий раз - слили и уровняли предыдущий слив в базе филиала.

**Konst_One** » 27.01.2006 (Пт) 11:57

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

**NRJ** » 27.01.2006 (Пт) 12:13

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

Я прекрасно всё это понимаю и морально готов. Но вопрос не в этом. Жду практических советов, быть может здесь есть какие-то подводные камни, часто встречающиеся ошибки. А говорить о том что это всё настолько сложно что лучше не связывайся - не решение проблемы! :shock:

**Konst_One** » 27.01.2006 (Пт) 12:24

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

**NRJ** » 27.01.2006 (Пт) 14:31

Konst_One писал(а):я бы все-таки посоветовал иметь единые справочники на стороне сервера, которые рассылаются филиалам и которые они не имееют права менять. а если им надо что-то туда добавить, то делать это они должны в отдельную структуру, которую пересылать на сервер, который будет в полуавтоматическом режиме (под контролем опытного пользователя) вносить в базу изменения и отправлять обратно таблицу разногласий по результатам работы.

Про справочники это хорошая мысль, спасибо. А как можно поступать с данными основной таблицы, ситуация описана в сообщении от 27.01.2006 (Пт) 10:04

**alibek** » 27.01.2006 (Пт) 14:39

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

**NRJ** » 27.01.2006 (Пт) 16:26

alibek писал(а):Написали же.
В каждой таблице для каждой записи фиксируешь дату обновления, номер версии и статус (новая запись, измененная запись, удаленная запись).
После чего на основании этих данных проводишь репликацию.
Сложность тут не в идее, а в реализации.

Всё понятно это я тормоз, не догоняю номер версии - это номер бд на местах?
Попробую реализовать. и с понедельника отпишусь что получилось.

**blinow** » 27.01.2006 (Пт) 16:35

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

**Andrey Fedorov** » 27.01.2006 (Пт) 16:49

alibek писал(а):Нужна репликация в обе стороны (от филиалов в центр и от центра в филиалы) или только в одну?
Для каждой записи хранить дату последнего изменения (дата и время) и счетчик изменений (целое). Ну и при слиянии ориентироваться на эти значения.

Да... Как-то писал подобное - на 40 таблиц...
Честно говоря больше не хочется. Но работало.

**alibek** » 27.01.2006 (Пт) 17:00

Andrey Fedorov писал(а):Да... Как-то писал подобное - на 40 таблиц...
Честно говоря больше не хочется. Но работало.

Сколько седых волос это добавило?

**Andrey Fedorov** » 27.01.2006 (Пт) 17:04

alibek писал(а):
Andrey Fedorov писал(а):Да... Как-то писал подобное - на 40 таблиц...
Честно говоря больше не хочется. Но работало.

Сколько седых волос это добавило?

Да виски поседели, точно. :cry:

Это же для каждого удаленного места версию отслеживать надо было.
Хорошо еще что справочные таблицы заполнялись только в центре - из можно было односторонне синхронизировать. Но часть требовалось двусторонне, с приоритетом центра.

**Sebas** » 27.01.2006 (Пт) 23:07

Ага, а как такие вещи, как неправильное время на компе или старые данные? Тут столько подводных камней...
И все равно, рассинхронизацию, практически, не избежать.

**Konst_One** » 28.01.2006 (Сб) 17:19

это точно, проще купить возможность прямого доступа к центральной базе через любой телекоммуникационный канал :wink:

**Andrey Fedorov** » 30.01.2006 (Пн) 7:50

Sebas писал(а):Ага, а как такие вещи, как неправильное время на компе или старые данные? Тут столько подводных камней...
И все равно, рассинхронизацию, практически, не избежать.

Для этого есть версия. То бишь формируется пакет с данными не ниже определенной версии и отправляется на другую сторону. С другой стороны формируется подтверждение приема/синхронизации данных и вместе с новыми данными отправляется назад... И так далее. В принципе система работала нормально.

**codemaster** » 30.01.2006 (Пн) 10:28

NRJ писал(а):Есть несколько подразделений одной конторы разбросанных на большие расстояния. Необходимо ведение баз данных на местах и централизация данных в одном месте.

Есть чудная вещь от MS -> MSMQ
думаю стоит посмотреть в ее сторону

**Sebas** » 30.01.2006 (Пн) 14:44

codemaster писал(а):
NRJ писал(а):Есть несколько подразделений одной конторы разбросанных на большие расстояния. Необходимо ведение баз данных на местах и централизация данных в одном месте.

Есть чудная вещь от MS -> MSMQ
думаю стоит посмотреть в ее сторону

Это равнозачно ответу: Используй блютуз!
Это всего лишь транспорт)))))))

Конференция VBStreets

Распределённая база данных

Распределённая база данных

Re: Распределённая база данных

Re: Распределённая база данных

Кто сейчас на конференции