Hi M0r0!

> если был бы драйвер-фильтр на файловую систему.

Это как раз не очень сложно - гораздо сложнее понять что же за изменение то
произошло - т.е. этот "фильтр" по сути должен содержать ядро СУБД - чтобы
для него происходящие в таблице изменения были не просто "заменой байтиков",
а реально "логическими единицами работы" - т.е. он должен из потока выделять
"записи", "поля" и т.п.
А с учётом того что обычно изменяется не 1 файл а несколько (не только
dbf+cdx - гораздо сложнее когда идёт согласованное изменение нескольких
таблиц) - и при этом отследить начало/завершение транзакции извне фокса (или
той программы/среды которая работает с данными)... В общем я очень
сомневаюсь что из этого может выйти хоть какой-то толк... Даже просто
"добавить триггера в базу не меняя саму программу" и то видимо будет
недостаточно для полноценной реализации системы репликации на фоксе.

Posted via ActualForum NNTP Server 1.3

Hi Sergey!

Эту программу (если ты про FoxAudit) стоит хотя-бы посмотреть начинающим
заниматься аудитом (или репликацией на основе ведения транзакционного
лога) - благо у неё есть демо-версия (по крайней мере когда-то была :) )

Posted via ActualForum NNTP Server 1.3

Hi M0r0!

Каждое решение имеет свою сферу применения :) Так что я более чем уверен,
что для твоей задачи эта схема будет вполне работоспособной.

Что касается недостатков, или того чего нет вообще:
- синхронизация НСИ, если её могут корректировать "на местах" - или тех-же
записей "оперативных таблиц", если и их могут менять не только не одном
узле - говоря кратко - надо решать проблему сходную "конфликту обновлений"
при оптимистической буферизации - только уже гораздо позже собственно
момента внесения изменений.
- проблема неполноты - скажем из 10 узлов пришла информация а из одного
нет - пропускать по твоей схеме нельзя - значит ждём пока и этот "тормоз"
пришлёт пакет обновления.
- проблема удаления - в реплицируемых базах надо реализовывать
многоступенчатую схему удаления (ибо нельзя удалить без проверки на всех
узлах - вдруг там есть/т.е. появились ссылки на эту запись)
- проблема целостности транзакций - никак не прописано то, что обновления в
логе не атомарны/независимы, а обычно множественны, и должны окружаться
транзакцией - т.е. не просто по очереди выполнять запросы из лога, а
создавать "пакеты"...
Есть и много чего ещё - в целом проблема очень и очень непростая.

Posted via ActualForum NNTP Server 1.3

Hi M0r0!

> изменение одной и той же записи в двух и более БД

Именно так. Причём иногда нужно "по частям" принимать изменения - скажем в
атрибутах организации на одном узле исправили ФИО директора, на другом -
адрес на третьем ещё что-то... И в целом надо принять ВСЕ эти изменения - но
это весьма непросто...

А ещё проблема "совмещения дублей" - когда одного и того-же "гр. Иванова",
ну ли там "ООО Рога и Копыта" ввели в справочник сразу на нескольких узлах -
естественно "подвязав" к нему какие-то данные в других таблицах - при
слиянии, в центральном узле важно иметь инструмент "перекодирования" для
таких случаев.

> ЦБД у меня главная и на веру принимается, что информации поступающая от
> нее правильная.

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

> Тоже решена. Не имеет значения пришла ли информация от всех УБД или нет

Ты не про тот аспект беспокоишься :)
Дело не в объёме пакетов, а в самих данных - если в "том самом" потерянном
пакете была важная информация - ну например о том что единственный поставщик
товара А разорился, и поставок больше не будет - т.е. надо снимать некоторый
товар с продажи, или искать другого поставщика - а про это никто не знает и
продолжает бодро лупить заявки... пример конечно выдуманный, но идея думаю
ясна.

> нумерации пакетов и подтверждений об их получении

Ага, а заодно и "таймауты" или нечто типа "TimeToLive" - чтобы не
перегружать поток обмена "неактуальными" подтверждениями и бесконечными
пересылками...

>> - проблема удаления
> в моей базе удаление очень редкая вещь.

В приницпе есть такие системы ведения данных, где удаления и не требуются -
там ВСЕ изменения (и удаление в том числе) осуществляется при помощи вставки
новых записей - со служебными полями типа "запись удалена".

> Тут вообще хотели реализовать каскадное обновление записей, когда
> какое-нибудь значение присутствует в нескольких базах и при его изменении
> надо поменять его во всех БД 8).

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

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

Дело не в этом.
Просто по своей сути пакет обновления это не "бессвязный набор единичных
операций", но и не "одна большая транзакция"!!! Т.е. в пакете многие
изменения группируются в свои наборы - вот тут мы меняем/вводим документ (а
это 10-20 единичных операций), тут меняем только одну позицию (это всего
одна операция) - и в общем случае ЛЮБАЯ из этих транзакций может "не пройти"
на центральной базе! А это значит что в твоей схеме не пройдёт весь пакет -
а это нехорошо - ибо другие то транзакции не связаны никак с "проблемной", и
нет резона их отменять из-за одной неудачной...
Видимо ты просто не соблюдаешь строго ссылочную целостность - т.е.
позволяешь появляться в таблицах и "сиротам", и прочим аномалиям - только в
лог пишешь про них - и надеешься что оператор найдёт время на анализ лога и
решение проблемы ;)

> Вот все думаю, что не верно выбрал формат журнала изменеий.

В принципе журнал изменений (и пакет репликации во многом тоже) должнен быть
похож на XML апдейтаграмму :) Или даже ЯВЛЯТЬСЯ ею. Как он будет
"повёрнут" - это уже не очень важно - будет он "элементно-базированным",
описывающим каждое изменение поля, или "строко-базированным", описывающим
изменение всей записи (но тогда надо и статус GETFLDSTATE(-1) не потерять!
Чтоб видеть какие поля реально "трогали")...

Posted via ActualForum NNTP Server 1.3