WildSery пишет:
On Tue, 26 Dec 2006 17:43:37 +0300, Tonal <[EMAIL PROTECTED]> wrote:
Единственное возражение - слияние данных, когда по одинаковым REPL_ID разные
данные.
Наверное, ты хотел сказать наоборот, когда по разным REPL_ID одинаковые данные.
И какие ты видишь проблемы при этом в предложенной мною схеме?
Которых нет в других схемах?
При обнаружении подобного дубляжа просто грохаем один из объектов, а
репликация это разносит по свету. ;-)
Разные данные по одному REPL_ID быть не может в принципе - ты утвердил,
что REPL_ID уникальны.
Но я не утверждал, что данные по одному REPL_ID в разных базах будут
идентичны.
Простой реальный пример - накладные курьерской доставки.
При приходе на склад-получатель состояние накладной изменяется.
В то же время, на складе-отправителе выявили ошибку в данных на эту
накладную, и исправили её.
Если и ошибочные данные, и состояние поля одной таблицы, то возникают
разные данные для одного REPL_ID и потребность их сливать.
Надо не просто "грохнуть", надо изменить и все ссылающиеся на
"убиваемый" объект записи.
Естественно. Но и в других системах нужно будет изменять ссылки.
В чём проблема то?
Или какая-то схема существенно облегчает эту задачу?
А вот если насрать на уникальность,
и у каждой базы поддерживать свои ID,
В "моей" схеме каждая база работает на своих ID.
REPL_ID нужен только для механизмов репликации. Это уникальный
идентификатор в пределах глобальный системы.
то изменятся только данные,
из более приоритетного источника.
Не совсем понял мысль.
А как быть, если нельзя сказать какой источник более приоритетный?
В обшем виде задача не решается. Посмотри, например, паралельный ответ
Коваленко.
