Болд отлично подходит для нписания локальных ИС(в пределах 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

В деревне как обеспечить доступ к серверу

Нужно также предусмотреть чтобы система работала даже в оффлайне
т.е. В конце допустим месяца скидывается на болванку обновление
что за месяц наработали и отправляется в главный офис для отчетности.
В случае автовокзала обновление идет каждый день т.е. либо ночью скачивается,
либо с первым автобусом едет;)

Я сейчас прорабатываю вариант трехзвенки с Грибачевским паком. Через пару месяцев расскажу о результате

Будем ждать