Dogen nomadeЗачем Вам всё-таки точная хронология?
Для разрешения update-конфликтов.

У Вас такой проблемы нет, зато у тех кто пользуется подобными системами, есть. И решают эту проблему отнюдь не красивыми способами - иногда и надо отредактировать запись в филиале компании, а не разрешают. Ждут центр.
В моей схеме репликации проблему тоже можно решить "некрасивым" способом:
разрешить изменения и заменить поле LOG_OWN_GEN "собственное поколение записи"
( см. пример таблицы данных )
на timestamp. Тогда для определения порядка изменений в БД будут по-прежнему использоваться поколения, а при разрешении конфликтов - timestamp.
Т.к. методов разрешения конфликтов много (timestamp, приоритет БД, разруливание вручную и т.п.), то я в прототипе эту проблему проигнорировал.
Можно напр. сделать как в Delphi: если мы изменили запись в филиале, отправляем в центр,
и выясняем, что в центре эту запись поменял кто-то другой, то запись возвращается обратно для ручного разруливания.

contr nomade Dogen nomadeЗачем Вам всё-таки точная хронология?
Для разрешения update-конфликтов.В моей схеме репликации проблему тоже можно решить "некрасивым" способом:
Уважаемый nomade, обратите внимание, что оперировать таблицами при построении перспективного (или неперспективного...) репликатора - не очень удачная идея по двум причинам:
1) Ваш продукт будет конкурировать со штатными решениями по репликации, присутствующими в арсенале любой СУБД. Причем конкурировать с заведомо проигрышной позиции, поскольку претендует на универсальность, в то время как решения от вендоров тесно интегрированы с СУБД.
2) Если Вы всерьез задумались о разрешении конфликтов встречных изменений, то обратите внимание на следующее: данные в БД обновляются транзакциями. Транзакция может затрагивать более одной таблицы и выполняться продолжительное время.

Пусть есть таблицы Т1, Т2 и их реплики R1, R2.
Пусть над T1, T2 проведена транзакция, поменявшая записи
T1Rec10 - в момент времени 10
T2Rec25 - в момент времени 20
В то же время над репликой было проведено похожее действо (встречное обновление):
R1Rec10 - в момент времени 12
R2Rec25 - в момент времени 18

К какому результату приведет Ваше "некрасивое" решение по разрешению конфликта на базе отдельных таблиц, поколений и timestamp? Гарантирует ли оно целостность (непротиворечивость) данных?

ИМХО если и строить что-то свое, то лучше на принципах, подобных изложенным tygra - с ориентацией на бизнес-смысл потоков данных, а не на их физическое хранение.

Ценные замечания.
2)Признаюсь, я про обновления на разных БД толком не думал.
А это, как оказалось, серьёзный недостаток.
На краткость транзакций надеяться не приходится, время и так не слишком надёжно.
Пока что вижу такое решение описанной Вами проблемы:
применить двухэтапную установку времени (как в поколениях) :).
Получится такая штука:
Пусть есть таблицы Т1, Т2 и их реплики R1, R2.
Пусть над T1, T2 проведена транзакция, поменявшая записи
T1Rec10 - момент времени: NULL
T2Rec25 - момент времени: NULL
Записи недоступны для репликации.
Перидически заупскается транзакция, кот. устанавливает поколения,
одновременно она устанавливает и время:
T1Rec10 - момент времени: 30
T2Rec25 - момент времени: 30
Записи доступны для репликации.
В то же время над репликой было проведено похожее действо (встречное обновление):
R1Rec10 - момент времени: NULL
R2Rec25 - момент времени: NULL
Потом установили время:
R1Rec10 - момент времени: 20
R2Rec25 - момент времени: 20
---
Целостность сохраняется (пока ИМХО. надо проверить:)
Время оценивается конечно грубовато.

1)Да я сознаю, что область применения самописных методик очень небольшая.
Но, судя по форумам, такая необходимость иногда всё-таки есть.
У меня пока не продукт а прототип, который ИМХО можно приспособить к конкретной ситуации.

contr
ИМХО если и строить что-то свое, то лучше на принципах, подобных изложенным tygra - с ориентацией на бизнес-смысл потоков данных, а не на их физическое хранение.

Мне сложно сказать.
Готовых репликаторов действительно много.
А описаний методик почему-то мало:) Может моя схема кому-то пригодится.

ShultzeЗря напали на человека
А по моему нормальный механизм репликации, сам применял подобный в паре проектов, идею придумал не я, взял отсюда:
Репликация AD
Если не касаться частностей, то это аналог приведенной реализации

Приятно слышать, что подходы, подобные моему, применяются на практике.
В статье, наск. я понял, речь идёт о репликации объектов.
Как этот подход можно применять к БД?

Dogen ShultzeЗря напали на человека
А по моему нормальный механизм репликации, сам применял подобный в паре проектов, идею придумал не я, взял отсюда:
Репликация AD
Если не касаться частностей, то это аналог приведенной реализации
А никто не спорит. Человек попросил заценить, а ему говорят, что мастер-слэйв неинтересно и в самом деле может быть реализовано встроенными средствами серверов (хотя я бы делал все сам, к примеру).
Обсуждение на форуме - неплохой способ для "стресс-тестирования" метода.
Кроме многочисленных достоинств моего метода обнаружились и некоторые недостатки:)
Несколько раз критиковалась схема мастер-слэйв. Похоже от неё таки прийдётся избавиться.
Вопрос к экспертам: достаточно ли позволить всем БД изменять чужие записи но запретить удаление? Или все БД должны иметь возможность и удалять чужие записи?

Dogen
В АД репликация сетевая, попарно между серверами, в режиме мастер-мастер. Ничего общего.
Сеть можно и у меня сделать: соединять БД можно как угодно и две БД могут одновременно реплицироваться друг с другом.
(правда, не мультимастер:( )

Dogen nomadeВопрос к экспертам: достаточно ли позволить всем БД изменять чужие записи но запретить удаление? Или все БД должны иметь возможность и удалять чужие записи?
Это к заказчикам вопрос, а не к экспертам. Если Вы занимаетесь общим случаем, то всё нужно.
С удалением и так проблем много:)
Тогда можно по-другому спросить: насколько часто втречается необходимось удалять чужие записи?
(хотя конечно если делать общий алгоритм, то надо или всё запретить или всё разрешить:)

DogenУ Вас какой-то подход не от жизни.

Удалять на определенном уровне абстракции надо разрешать всё, а запрещать - это уже уровень выше, т.е. уровень бизнес-логики.

При этом физического удаления записей не должно происходить.

Просто я не привязываюсь к конкретным примерам.

Валентин КДля централизованных систем линейная репликация серверов БД не годится.. и интересно, кто расскажет что это не так...

наск. я понял, для ценрализованных систем не годится репликация "каждый с каждым".
т.к. иерархическая система проще, то из репликации "каждый с каждым" всегда можно сделать репликацию "центр-филиалы".

Валентин К
Статью прочитал бегло, не понял зачет версионность.

Если имеется ввиду поле LOG_OWN_GEN "собственное поколение записи"
(см. пример таблицы данных) , то оно для разрешения кофликтов обновления.

Если вы про поколения, то они для того, что бы определить какие изменения произошли.
Клиенту достаточно хранить одно число - старое значение счётчика поколений сервера,
что бы понять, что на сервере изменилось.
Валентин К
Практическая модель централизованной репликации есть, что тоже не велосипед.

Я не спорю. Даже привёл список ссылок на другие статьи.

Валентин К
Зачем вообще версионность и зачем по ней определять что-то? это тупиковая мысль, рабочая, но иррациональная. Можете применять. Но реально лучше сделать проще, надежней и быстрее.

Обоснуйте своё высказывание.
Что конкретно Вы предлагаете взамен?