|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Dmitry Batsuro 2:5020/720.10 21 Apr 2001 02:50:13
To : All
Subject : Взаимное дополнение баз
--------------------------------------------------------------------------------
Возможно, кто-нибудь из присутствующих здесь решал такую проблему. Или, может
быть, может указать, где ее решение описано в литературе или Интернете.
Итак, задача следующая. Если две базы данных одинаковой структуры в разных
городах. Между машинами, на которых они стоят в одном и в другом городе, нет
надежного канала связи. В каждую базу вносятся изменения, и требуется
периодически (допустим, раз в час) взаимно дополнять каждую базу изменениями
другой. При этом, поскольку нет надежного канала, предполагается изменения базы
(измененные и вновь созданные записи) выталкивать в файл в каком-то своем
формате и отправлять, скажем, по e-mail на другую сторону. Hасколько я понял,
это не есть репликация в классическом смылсе, поскольку она подразумевает
взаимное дополнение баз при их сравнении, что невозможно при отсутствии
надежного канала.
В общем-то, все просто, но тут возникают следующие проблемы. Во-первых, как
обеспечить контроль за доставкой пакетов на другую сторону? Ведь ни для кого не
секрет, что e-mail может идти довольно долго и, в результате, даже не дойти. Или
два письма могут прийти не в том порядке, в котором были посланы. Hо ведь важно
заливать в БД обновления, пришедшие от другой БД, именно в том порядке, в
котором они производились.
Во-вторых, проблема асинхронности изменений. Hапример, в каждом из городов в
одну и ту же запись внесли разные изменения; скажем, в одном изменили фамилию
клиента, а в другом - его юридический адрес. При взаимном дополнении, когда
каждая сторона пошлет другой изменения, эта запись станет такой, как на другой
стороне до взаимного дополнения. То есть они будут снова различаться. Как
решается этот конфликт? Можно ли его решить, если пересылать не измененные
записи, а отдельные поля?
В-третьих, как решается проблема уникальности первичных ключей? Hапример, в
каждом из городов насоздавали записей с автоинкрементным индексом, который
уникален в пределах БД данного города, но в разных городах может быть две разных
записи с одинаковым ключом. При взаимном дополнении запись, присланная с
удаленной стороны, должна получить новый уникальный ключ. Как в этом случае
отслеживается соответствие записей в базах и сохраняется ссылочная целостность?
В общем, жду от вас любой информации по данному вопросу. Практические
рекомендации, сслыки на литературу в бумажном и электронном варианте и т.п.
See thee anon, All! BACHELOR DiBa
Teams [The Beatles] [Guitar] 2:5020/720.10 aka /3700.4800
[1180'95] [MSTU] [Discotheques sux] aka /484.84 aka 476:751/2.22
---
* Origin: Ты прав, брат: я халявщик, брат... (2:5020/720.10)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
