Re[3]: Создание РБД
От: ЛёХыЧ Россия  
Дата: 18.05.10 03:24
Оценка:
И еще одно ограничение которое вводит SQL Server Compact 3.5 он не поддерживает хранимые процедуры или представления. Так что данный вариант отпадает, почти все запросы из БД делаются StoreProc.
Re[7]: Создание РБД
От: Ziaw Россия  
Дата: 18.05.10 03:56
Оценка:
Здравствуйте, Ellin, Вы писали:

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

E>Лично я бы не рискнул.

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

Система работает уже лет 5 нормально.
Re[8]: Создание РБД
От: ЛёХыЧ Россия  
Дата: 18.05.10 04:02
Оценка:
Здравствуйте, Ziaw, Вы писали:

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


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

E>>Лично я бы не рискнул.

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


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


Раскажи общий смысал реализации системы.
Re[9]: Создание РБД
От: Ziaw Россия  
Дата: 18.05.10 15:38
Оценка: 5 (1)
Здравствуйте, ЛёХыЧ, Вы писали:

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


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

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

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

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

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

Как-то так.
Re[10]: Создание РБД
От: ЛёХыЧ Россия  
Дата: 19.05.10 03:32
Оценка:
Здравствуйте, Ziaw, Вы писали:

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