Здравствуйте, ЛёХыЧ, Вы писали:

ЛёХ>Раскажи общий смысал реализации системы.

Это школьный документооборот. Общий смысл таков, все данные заполняются в школах и стекаются в краевой центр через районные базы. Т.е. трехуровневая схема: школа обменивается репликами с роно, роно с краем. В другую сторону данных идет совсем мало: обновление справочников, данные по ученикам которые прибыли из других школ. В итоге в крае получается общая картина по всем ученикам, учителям, учебным планам, приказам. Таблиц 200 или больше, я уже не помню. К системе предъявлялись достаточно жесткие требования по отказам т.к. раз в год формируется туева хуча отчетов по всем данным. Естественно выпадение даже одной школы из репликации (на начало работы их в крае было более 1300) недопустимо. Ибо цифры сразу поплывут и какой-то район недополучит денег например. Поэтому, а еще потому, что бывают моменты, когда до некоторых школ только вертолетом и по рации репликация стала самой неприхотливая к каналам связи, построена на сообщениях.

Как все устроено: каждая база получает диапазон идентификаторов которого теоретически ей хватит лет на тыщу. Все записи создаются с ключами по возрастанию из этого диапазона. На каждую таблицу вешаются CUD триггеры которые записывают айдишник и действие в таблицу лога (лог тоже с этим айдишником). Еще есть таблица соседних баз в которой хранится достоверно известный максимальный принятый ей айдишник записи лога.

Формируем посылку так: выбираем все записи лога айдишник которых больше того известного, пихаем в пакет все записи у которых в логе стоит создание или изменение. Ну и записываем айдишники удаленных записей. К посылке прикладываем максимальный принятый от той базы ключ, когда она его получит — запишет в свою таблицу соседних баз в нашей строке.

Самый геморой при приеме связан с отсутствием в фаерберде констрейнтов которые умеют проверяться при комите (deffered). И тем фактом, что констрейнты нельзя прибить или создать в дмл транзакции. Посему пришлось писать алгоритм разруливания зависимостей, который выстраивает данные в нужном порядке. После этого данные соотвественно вставляются, обновляются и удаляются.

Все возможные конфликты пресекались на уровне БЛ либо ресолвились автоматом в стиле "последний прав".

Как-то так.

Добрый день,

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

Здравствуйте, ЛёХыЧ, Вы писали:

ЛёХ>Добрый день,

ЛёХ>возникла потребность создание программы с возможностью распределенной БД, кто что может посоветовать и где можно почитать. в поиск нечего хорошего не дает. Прочитал статью про журналирование данных, с использованием тригиров. которые будут ставить время последнего изменения или создания в табличку, и дополнительно вести таблицу в которую будут заносится данные о все изменениях в базе по соотвествующим полям.
Ну очень интересно каким образом возникла такая потребность.

Здравствуйте, Ellin, Вы писали:

E>Ну очень интересно каким образом возникла такая потребность.

Из за того что появились подразделения, и в каждом из подразделений будет установлено данное ПО, а все данные должны собираться в единую БД. Если приводить пример то по принципу 1С РБД (импорт-экспорт).

Здравствуйте, ЛёХыЧ, Вы писали:

ЛёХ>Из за того что появились подразделения, и в каждом из подразделений будет установлено данное ПО, а все данные должны собираться в единую БД. Если приводить пример то по принципу 1С РБД (импорт-экспорт).
А что мешает сделать трехзвенку с подключением всех клиентов к одной базе?

Здравствуйте, ЛёХыЧ, Вы писали:

ЛёХ>Здравствуйте, Ellin, Вы писали:

E>>Ну очень интересно каким образом возникла такая потребность.

ЛёХ>Из за того что появились подразделения, и в каждом из подразделений будет установлено данное ПО, а все данные должны собираться в единую БД. Если приводить пример то по принципу 1С РБД (импорт-экспорт).
Ну ясно. Смотрите в сторону репликации.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, ЛёХыЧ, Вы писали:

ЛёХ>>Из за того что появились подразделения, и в каждом из подразделений будет установлено данное ПО, а все данные должны собираться в единую БД. Если приводить пример то по принципу 1С РБД (импорт-экспорт).
А>А что мешает сделать трехзвенку с подключением всех клиентов к одной базе?

На некоторых точках инет очень худой. доходит до dialup.

Здравствуйте, ЛёХыЧ, Вы писали:

ЛёХ>возникла потребность создание программы с возможностью распределенной БД, кто что может посоветовать и где можно почитать. в поиск нечего хорошего не дает. Прочитал статью про журналирование данных, с использованием тригиров. которые будут ставить время последнего изменения или создания в табличку, и дополнительно вести таблицу в которую будут заносится данные о все изменениях в базе по соотвествующим полям.
Посмотри на SymmetricDS (http://symmetricds.codehaus.org/) — он на Java, но его можно использовать и в .NET без особых проблем.

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

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, ЛёХыЧ, Вы писали:

C>Там он строит хитрые триггеры и с помощью них ловит изменения
А если база не поддержичает триггеры

Здравствуйте, Аноним, Вы писали:

C>>Там он строит хитрые триггеры и с помощью них ловит изменения
А>А если база не поддержичает триггеры
А какая база их не поддерживает?

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, Аноним, Вы писали:

C>>>Там он строит хитрые триггеры и с помощью них ловит изменения
А>>А если база не поддержичает триггеры
C>А какая база их не поддерживает?
SQL Compact edition, например.

Здравствуйте, Ellin, Вы писали:

C>>>>Там он строит хитрые триггеры и с помощью них ловит изменения
А>>>А если база не поддержичает триггеры
C>>А какая база их не поддерживает?
E>SQL Compact edition, например.
Ну так не использовать их, значит. Взять какой-нибудь Firebird (поддерживается в SymDS) и не мучатся.

Здравствуйте, Cyberax, Вы писали:
E>>SQL Compact edition, например.
C>Ну так не использовать их, значит. Взять какой-нибудь Firebird (поддерживается в SymDS) и не мучатся.
Лично я бы не рискнул.

Здравствуйте, Ellin, Вы писали:

E>>>SQL Compact edition, например.
C>>Ну так не использовать их, значит. Взять какой-нибудь Firebird (поддерживается в SymDS) и не мучатся.
E>Лично я бы не рискнул.
А обрезанный SQL CE — так рискнул бы? Странно...

Здравствуйте, Cyberax, Вы писали:

C>А обрезанный SQL CE — так рискнул бы? Странно...
Может и обрезанный зато стабильно работает.

Я использую MySQL, а он поддерживает триггеры.
В принципе вариант использование триггеров очень удобен, можно не изменяя алгоритма обмена в программе, а только описывая для каждой новой таблицы набор триггеров для команд (INSERT, UPDATE, DELETE). Заполняя в таблице журналирования имя таблицы и другую служебную информацию. Остается только один вопрос это ключевое поле в БД. Но наверное уже другая тема. В принципе использовать в начале id колонки ASCII код префикса БД.

Здравствуйте, Ellin, Вы писали:

C>>А обрезанный SQL CE — так рискнул бы? Странно...
E>Может и обрезанный зато стабильно работает.
Так и FB тоже стабильный. Кстати, в чём "стабильность" измеряется?

Здравствуйте, ЛёХыЧ, Вы писали:

ЛёХ>Я использую MySQL, а он поддерживает триггеры.
ЛёХ>В принципе вариант использование триггеров очень удобен, можно не изменяя алгоритма обмена в программе, а только описывая для каждой новой таблицы набор триггеров для команд (INSERT, UPDATE, DELETE). Заполняя в таблице журналирования имя таблицы и другую служебную информацию. Остается только один вопрос это ключевое поле в БД. Но наверное уже другая тема. В принципе использовать в начале id колонки ASCII код префикса БД.
Бери SymDS — он сгенерирует триггеры автоматически. Там вообще вся готовая инфраструктура для репликации уже есть.

Здравствуйте, Cyberax, Вы писали:

C>Бери SymDS — он сгенерирует триггеры автоматически. Там вообще вся готовая инфраструктура для репликации уже есть.

Уже скачал, сейчас разбираюсь, единственно что он на Java.

Здравствуйте, ЛёХыЧ, Вы писали:

ЛёХ>Добрый день,

ЛёХ>возникла потребность создание программы с возможностью распределенной БД, кто что может посоветовать и где можно почитать. в поиск нечего хорошего не дает. Прочитал статью про журналирование данных, с использованием тригиров. которые будут ставить время последнего изменения или создания в табличку, и дополнительно вести таблицу в которую будут заносится данные о все изменениях в базе по соотвествующим полям.


Не занимайся ерундой. Возьми обычный компакт едишин и юзай проект в студии типа локал датабейс кеш. Он позволит делать синхронизацию. Разберись что к чему и пользуйся на здоровье.

Здравствуйте, Ciget, Вы писали:

C>Не занимайся ерундой. Возьми обычный компакт едишин и юзай проект в студии типа локал датабейс кеш. Он позволит делать синхронизацию. Разберись что к чему и пользуйся на здоровье.

Если внимательно посмотреть на то, что создоет мастер — это просто набор триггеров для таблица типа AFTER (INSERT, UPDATE, DELETE).

И еще одно ограничение которое вводит SQL Server Compact 3.5 он не поддерживает хранимые процедуры или представления. Так что данный вариант отпадает, почти все запросы из БД делаются StoreProc.

Здравствуйте, Ellin, Вы писали:

C>>Ну так не использовать их, значит. Взять какой-нибудь Firebird (поддерживается в SymDS) и не мучатся.
E>Лично я бы не рискнул.

Разрабатывал систему с распределенной БД. Центральная БД на оракле, ее кусочки на фаерберде распределяются на более 1000 рабочих мест. Репликация самописаная, оффлайновая, одно из требований к системе — "чтобы данные можно таскать на дискетке", система стоит в таких районах в которых до сих пор нет нормального интернета, данные реплицируются оказией раз в месяц. Особых претензий к фаерберду нет, хотя оптимизатор там уступает оракловому (по крайней мере одни и те же запросы выполняемые ораклом за милисекунды на ФБ могут тормозить до 20 секунд, их требуется тюнить, впрочем это отдельные классы запросов про которые надо знать).

Система работает уже лет 5 нормально.

Здравствуйте, Ziaw, Вы писали:

Z>Здравствуйте, Ellin, Вы писали:

C>>>Ну так не использовать их, значит. Взять какой-нибудь Firebird (поддерживается в SymDS) и не мучатся.
E>>Лично я бы не рискнул.

Z>Разрабатывал систему с распределенной БД. Центральная БД на оракле, ее кусочки на фаерберде распределяются на более 1000 рабочих мест. Репликация самописаная, оффлайновая, одно из требований к системе — "чтобы данные можно таскать на дискетке", система стоит в таких районах в которых до сих пор нет нормального интернета, данные реплицируются оказией раз в месяц. Особых претензий к фаерберду нет, хотя оптимизатор там уступает оракловому (по крайней мере одни и те же запросы выполняемые ораклом за милисекунды на ФБ могут тормозить до 20 секунд, их требуется тюнить, впрочем это отдельные классы запросов про которые надо знать).

Z>Система работает уже лет 5 нормально.

Раскажи общий смысал реализации системы.

Здравствуйте, Ziaw, Вы писали:

Спасибо, очень понятно расписали и дохочево. теперь можно собрать все мысли и попробывать реализовать. тестовый вариант.