Форум Сообщества Аналитиков
Общий раздел => Методологии => MDA => Тема начата: SaTim от 01 Июля 2008, 12:10:30
-
Болд отлично подходит для нписания локальных ИС(в пределах 1 сети).
Но как только начинается распределение на несколько БД
разделеных территориально начинаються проблемы.
Итак проблема 1
Это выражения OCL типа (BoldClass).allInstances
при этом весь обьект все атрибуты, все ассоциации, генерализация
помещается в ОЗУ получается что с сервера на клиент передается много
информации. В пределах 1 сети это не страшно ну передалось на клиент 100 мб
за сеанс ничего страшного зато в дальнейшем работа с этими обьектами осуществляется
гораздо быстрее.
Одно из решений использовать SQL-пак написанный Константином Грибачевом
Проблема 2
Болд в своей базе создает 2 дополнительных служебных поля
BOLD_ID и BOLD_TYPE кторые уникальны в пределах 1 базы данных
Проблема возникает в том что когда из вторичных баз реплицируються
данные в главную Болд создаст эти поля в своей нумерации отличное от
нумерации во вторичной базе.
Есть 2 инженерных решения первое расковырять Болд и поправить под свои нужды
и второе создать свои ID и TYPE уникальные для всей системы и научить болд работать с ними.
У кого какие мысли по поводу проблем.
-
по первой проблеме.
А ежели научить OCL осуществлять нечто, что имеется например в mysql с лимитом + несколько перестроить компоненты дескрипторов на возможность авто подгрузки данных при смене прокуртки.
по второй проблеме - получается лучше как-то научить болд формировать собственные пользовательские ID генераторы и работать с ними
-
Во-первых, надо понять зачем нужны распределенные БД?
Возможно ли это сделать с помощью трехзвенной архитектурой. Если да, то можно сервер приложения писать с помощью БОЛД
-
Во-первых, надо понять зачем нужны распределенные БД?
Нет не база распределеная а ИС распределеная.
Случай когда есть головной офис и филиалы в др городах. Например.
-
Да тут проблема репликации данных.
Т.е. каждый объект уникален и этот процесс не контролируется, нет средств реплицирования под болдом. Потому и возникла проблема, как сливать реплики
-
Нет не база распределеная а ИС распределеная.
Случай когда есть головной офис и филиалы в др городах. Например.
И что?? Почему трехзвенка не поможет??
И еще одно - нужно тогда писать отдельно ПО для филиалов и отдельно для центра, куда все сливается.
-
И еще одно - нужно тогда писать отдельно ПО для филиалов и отдельно для центра, куда все сливается.
В большинстве случаях отдельное ПО для филиалов и центра слишком затратно разрабатывать и поддерживать
-
И что?? Почему трехзвенка не поможет??
В деревне как обеспечить доступ к серверу, когда у них канал узкий? Вот потому трехзвенка и не катит. Только обновление по ftp. А разные приложения - это в данном случае не comme il faut
-
В деревне как обеспечить доступ к серверу
Нужно также предусмотреть чтобы система работала даже в оффлайне
т.е. В конце допустим месяца скидывается на болванку обновление
что за месяц наработали и отправляется в главный офис для отчетности.
В случае автовокзала обновление идет каждый день т.е. либо ночью скачивается,
либо с первым автобусом едет;)
-
Я сейчас прорабатываю вариант трехзвенки с Грибачевским паком. Через пару месяцев расскажу о результате :)
-
Будем ждать :)