Распределенная база данных на основе View

[sukhanchik]

Рабочая система некоторое время на похожей схеме работала. Впоследствии от данной системы отказались (по независящим от системы причинам), однако, в т.ч. для экономии времени на разработку и сопровождение.
Что еще можно добавить:
+Уменьшение взаимоблокировок - т.к. данные находятся физически в разных БД (для SQL Server это актуально)
-Индексируются таблицы, а не представления, поэтому поддерживаю утверждение про производительность. Это кстати - ключевой момент. Если какая-нибудь форма (типа InventTable, особенно, если она была доработана - к примеру добавлен древовидный справочник) будет открываться минут 5 - то такая производительность может стать узким местом.
-/+ Необходимо допиливать синхронизацию. Дело-то в общем не такое сложное - но требует времени и аккуратности - есть некоторый перечень таблиц - который должен оставаться таблицами - иначе Аксапта просто не запустится (В качестве примера - приведу таблицу LanguageTable, еще список торчит в классе Application.syncApplTables, но я не утверждаю, что сей список исчерпывающий).
-/+ Сложности с накатыванием нового клиента Аксапты, который меняет версию таблиц в табл. SQLSystemVariables - там синхронизация делается ядром и не отлавливается. Когда в KR1 добавили новое поле во все таблицы (recVersion), то данное поле пришлось пробить во всех "вьюшных" и "невьюшных" таблицах вручную.
-/+ Сложности при разработке (нужно добавлять поле во все таблицы, а затем перестраивать вьюхи - т.к. они не обновляются, плюс необходимо решить вопрос с индексами, т.к. индекс на вьюхе не создается, однако его бывает полезно создать на таблице)
-/+ Сложности при обновлении (особенно - если нужно быстро позарез добавить поле в таблицу).

В общем-то эти все сложности решаются - поэтому я и пометил их как -/+, но я бы не сказал - что они облегчают сопровождение данного приложения.
Только производительность может стать неприятным сюрпризом (собсно index hint убирать и не надо - только если есть проблемы с конкретным случаем).