Здравствуйте, RagimAtom, Вы писали:
RA>Задача: По региону десятки компов, с возможно разыми РСУБД. Нужна RA>репликация вносимых изменений в БД. Все узлы равноправны, RA>т.е. репликация двух сторонняя.
RA>Реализация: RA>Прога, которая: RA>1) (желательно) независила от РСУБД. RA>2) реплицировала только вносимые изменения. RA>3) сразу бы передовала данные или создовала очередь, а потом RA>передовала.
Я конечно "не настоящий сварщик", но я б делал свою систему.
1) Делается унифицированный файлик например *.mdb, который будет включать в себя всю инфу, которая может быть обновлена, для всех возможных в регионе баз.
*.mdb хороша тем, что ниччё на систему дополнительного ставить ненадо ODBC'шные дрова для неё в мастдае по умолчанию есть + rar их сжимает до 2-3% + там какая-никакая а защта данных имеется.
2) Беруться все РСУБД, которые стоят в регионе и для каждой делается DLL, которая будет переконверчивать измененные данные между конкретной вариацией БД региона и этой унифицированной *.mdb.
DLL конечно должно быть много и они должны иметь унифицированный интерфейс.
3) Делается программулина, которая (допустим по мылу) архивированные *.mdb'шки по расписанию рассылает всем и, принимает присланные *.mdb, выстраивает их в очередь и скармливает dll'ке.
Дальше Dll'ка сгенерит mdb, программулина оный всем отправит или mdb'шка пришла и Dll её скормили.
Просто если всё такое разное, то нет гарантии, что всё поддерживает репликацию и глюков не будет. А так, прога одна, Dll много, данные в одном формате.
RA>_И ещё как сделать так чтобы можно было узнать что в БД произошли изменения, и какие изменения.
А вот это всё прописывается в Dll, для каждой РСУБД...
Наука изощряет ум; ученье вострит память.
(c) Козьма Прутков
Здравствуйте, ZAMUNDA, Вы писали:
ZAM>Я конечно "не настоящий сварщик", но я б делал свою систему.
А теперь, как это сделано у "сварщиков"
ZAM>1) Делается унифицированный файлик например *.mdb, который будет включать в себя всю инфу, которая может быть обновлена, для всех возможных в регионе баз.
Проектируется БД для хранения данных и связей между ними. Это как минимум. Там еще группировка данных по пакетам и источникам. Данные реплицируемых элементов можно хранить в виде XML.
ZAM>*.mdb хороша тем, что ниччё на систему дополнительного ставить ненадо ODBC'шные дрова для неё в мастдае по умолчанию есть + rar их сжимает до 2-3% + там какая-никакая а защта данных имеется.
Все равно прийдется ставить свои "дрова" для управления репликацией. Так что это не аргумент.
ZAM>2) Беруться все РСУБД, которые стоят в регионе и для каждой делается DLL, которая будет переконверчивать измененные данные между конкретной вариацией БД региона и этой унифицированной *.mdb.
Пишется унифицированный менеджер репликации и набор управляющих скриптов, которые специализированы под каждую структуру БД.
ZAM>DLL конечно должно быть много и они должны иметь унифицированный интерфейс.
Унифицированность сама по себе великая вещь
ZAM>3) Делается программулина, которая (допустим по мылу) архивированные *.mdb'шки по расписанию рассылает всем и, принимает присланные *.mdb, выстраивает их в очередь и скармливает dll'ке. ZAM>Дальше Dll'ка сгенерит mdb, программулина оный всем отправит или mdb'шка пришла и Dll её скормили.
"Прекрасное далёко ..."
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Задача: По региону десятки компов, с возможно разыми РСУБД. Нужна
репликация вносимых изменений в БД. Все узлы равноправны,
т.е. репликация двух сторонняя.
Реализация:
Прога, которая:
1) (желательно) независила от РСУБД.
2) реплицировала только вносимые изменения.
3) сразу бы передовала данные или создовала очередь, а потом
передовала.
Вопрос: какие методы использовать, с помошью каких программных средств это реализовать (VS, delphi, CORBA, ADO, COM ).
_И ещё как сделать так чтобы можно было узнать что в БД произошли изменения, и какие изменения.
Здравствуйте, RagimAtom, Вы писали:
RA>Задача: По региону десятки компов, с возможно разыми РСУБД. RA>Нужна репликация вносимых изменений в БД. Все узлы равноправны, RA>т.е. репликация двух сторонняя.
Эти требования несколько противоречивы.
Нужен механизм разрешения конфликтов, который признает чьи-то данные "более правильными".
RA>Реализация: RA>Прога, которая: RA>1) (желательно) независила от РСУБД.
Значит, скрипты на общем подмножестве ANSI SQL.
RA>_И ещё как сделать так чтобы можно было узнать что в БД произошли изменения, и какие изменения.
У каждой используемой СУБД нужно изучить механизмы, имеющиеся для этого и написать несколько реализаций этого сервиса с общим интерфейсом.
P.S. Если сюда заглянет г-н Softwarer, он наверное поделится своим богатым опытом.
Здравствуйте, wildwind, Вы писали:
RA>>Нужна репликация вносимых изменений в БД. Все узлы равноправны, RA>>т.е. репликация двух сторонняя. W>Эти требования несколько противоречивы.
Не вижу противоречий
W>Нужен механизм разрешения конфликтов, который признает чьи-то данные "более правильными".
Разруливание конфликтов имеет очень косвенное отношение к двунаправленной репликации.
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, Коваленко Дмитрий, Вы писали:
RA>>>Нужна репликация вносимых изменений в БД. Все узлы равноправны, RA>>>т.е. репликация двух сторонняя. W>>Эти требования несколько противоречивы.
КД>Не вижу противоречий
При двунаправленной репликации могут возникать конфликты. Логика их разрешения должна находиться в одном месте (узле). => неравноправие.
Возможен другой вариант — мастер-реплика, путешествующая между узлами. Но в нашем случае требуется инкрементная репликация, поэтому не подходит.
Здравствуйте, wildwind, Вы писали:
RA>>>>Нужна репликация вносимых изменений в БД. Все узлы равноправны, RA>>>>т.е. репликация двух сторонняя. W>>>Эти требования несколько противоречивы.
КД>>Не вижу противоречий
W>При двунаправленной репликации могут возникать конфликты. Логика их разрешения должна находиться в одном месте (узле). => неравноправие.
W>Возможен другой вариант — мастер-реплика, путешествующая между узлами. Но в нашем случае требуется инкрементная репликация, поэтому не подходит.
Я думаю, парню надо будет сначало представить, что такое "репликация" и общий принцип её реализации
А ему тут сразу про конфликты и автоматизацию процесса
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Как узнать, что произошли изменения в БД и сообщать программе, реализующею всю логику репликации и учитывающую противоречия, что изменения произошли?
Можно это сделать с помощью триггеров и периодически опрашивать таблицу этих изменений.
Но перспектива делать триггеры в ручную, причём для каждой СУБД отдельно и опрашивать таблицу изменений периодически,
не привлекает.
Здравствуйте, RagimAtom, Вы писали:
RA>Меня мучает один вопрос!
RA>Как узнать, что произошли изменения в БД и сообщать программе, реализующею всю логику репликации и учитывающую противоречия, что изменения произошли?
Здравствуйте, wildwind, Вы писали:
W>Здравствуйте, RagimAtom, Вы писали:
RA>>Меня мучает один вопрос!
RA>>Как узнать, что произошли изменения в БД и сообщать программе, реализующею всю логику репликации и учитывающую противоречия, что изменения произошли?
W>
W>Они разные, понимаешь? У кого-то их нет вообще, там придется ручками, триггерами. А какие у тебя целевые СУБД, ты не говоришь.
RA>Oracle,MSsqlserver,Postgresql,MySql.
). 
