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

[MironovI]

Цитата:

Сообщение от Владимир Максимов

Вы даже не слышали о том, что ребята в "веселых костюмчиках" неожиданно приходят в гости и опечатывают сервера? Шифровали Вы там, не шифровали, они разберутся. А если просто выдернуть диск (физически) - попробуй его потом найди. Вы вообще где живете-то?

Вам же говорят - человек пробовал и получил падение производительности на простейших операциях на два порядка - этого вам не достаточно? Не достаточно того, что синхронизацию вы будете производить ручками?

А по поводу веселых костюмчиков, ну выдернете вы диск - съедите допустим даже его - чет я ни разу не видел, чтобы налоговая допустим ковырялась в шифрованных базах данных - это ниже их достоинства - они пойдут за первичкой и работать будут с первичкой в первую очередь

[Михаил Андреев]

Цитата:

Сообщение от MironovI

А по поводу веселых костюмчиков, ну выдернете вы диск - съедите допустим даже его - чет я ни разу не видел, чтобы налоговая допустим ковырялась в шифрованных базах данных - это ниже их достоинства - они пойдут за первичкой и работать будут с первичкой в первую очередь

С нынешними средствами связи даже необязательно данные в офисе хранить. Они могут быть не только за пределами офиса, но даже за пределами страны.

[Alex_K]

А в офисе поставить что-то очень похожее на сервер. Можно даже на него "белую" базу ежедневно клонировать.

[Vadik]

Цитата:

Сообщение от Владимир Максимов

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

Уу.. сколько эмоций..

Цитата:

Перечислите их, пожалуйста. Если возможно, без комментариев. Меня интересуют проблемы именно со стороны AXAPTA

Проблемы:
- отвалится любой DDL оператор
ALTER TABLE ADD
ALTER TABLE DROP COLUMN
CREATE INDEX
В общем, синхронизацию Вы будете выполнять вручную
- отвалятся любые операторы с INDEX HINT (причем их м.б. больше, чем вам кажется)
- производительность просядет конкретно

Вот. Хватит для начала. Как Вы и просили, без комментариев

Я так понял, ранее в ветке упоминались некие структуры.. Поищите в Курилке - была недавно шуточная ссылка на компанию, предоставляющую услуги в области ректальной криптографии

[Lazy_Tiger]

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

[Владимир Максимов]

Ну, что ж. Подвожу итоги:

1. Никто по такой схеме не работал. Самое большее, проводились некоторые тесты.
2. Схема в целом оценивается как работоспособная. Из возможных проблем выделились следующие:

• Производительность
• Синхронизация
• Необходимость отключить все Index Hint в коде или через настройки

Все проблемы решаемые. И даже не очень большими усилиями. Надо только отойти от привычного "стандарта".

PS: Эх, "забронзовели" Вы, ребята. Много слов, а что в "сухом остатке"?

[MironovI]

В сухом остатке - вернемся к этой теме, когда вы поработаете по этой схеме месяцев пару на проектной мощности и предоставите результат общественности

[sukhanchik]

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

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