?Ыснкс.
Maxim Boguk<>
при этом без "дубль исходных данных в таблице[ах] событий (как в лондайсте) нежелателе" вы никак не обойдетесь...
каким собственно образом вы себе представляете работу такой системы без лога всех изменений?
<>
0. для простоты --
FK [как минимум -- на реплицируемые таблицы]
в БД отсутствуют .
далее, -- тут 2 случая:
1. update PK разрешен
2. update PK запрещен.
если 2 -- то нас интересует [только] последнее событие с данным pk и [только] последнее актуальное данное по NEW.pk из самой таблицы, а не из лога. [если событие -- delete -- то кроме ключа тем паче ничего не нужно]
если 1 -- то видимо всё то же самое [интересует последнее событие по OLD.pk, и актулаьное состояние с NEW.pk [возможно -- вдоль цепи апдейтов пк]], но надо проверить, что в цепи событий с пк мы не обманем такой подход (пока тщательно не выверял диаграммы переходов).
покуда склоняюсь к тупому запрету смены всех pk триггерами. (это всё равно суррогаты)
другое дело, если на события репликации надо реагировать на подписчике в том же порядке, как на события на паблишере -- тогда, с необходимостью, всё катать строго по логам.
Я понял вашу идею... как правило бизнес логика требует чтобы изменения накатывались в том же порядке что происходят в мастере... иначе на реплике будет несогласованные данные время от времени что недопустимо.
Если в вашей задаче это нормально - тогда 100% придется что то свое писать.
Я бы предложил например вариант:
триггер который обновляет mtime строки при любом обновлении.
Внешняя база хранит у себя время последней синхронизации... и когда ей надо пересинхронизироваться просто выбирает все обьекты c мастер базы с mtime>"время последней синхронизации".
Работает и для 3 и для 4 (просто 4ре делают это регулярно автоматически).
Если надо синхронизировать 2-5-10 таблиц - решение простое и вполне дубовое (но надо реализовывать в приложении конечно).
--Maxim Boguk
www.postgresql-consulting.ru
