iscrafms_ustinovС распределенными базами очень уж много головняка.
...
То есть вариант с распределенными базами является, без сомнения, вполне работоспособным, но достаточно сложным при первоначальном проектировании и настройке и потребует много трудозатрат при поддержке.
я так понял это идет речь не о распределенных решениях в принципе, а конкретно о построении распределенной системе на базе 1С?
Я сталкивался с распределенными системами только на базе 1с (одна логическая база данных на нескольких машинах), и обсуждал именно 1с.
Другие внедрения с несколькими территориально разнесенными серверами, о которых я слышал (с использованием других систем), нельзя, как мне кажется, называть распределенными базами - там была реализована полуавтоматическая синхронизация справочников и выгрузка/загрузка некоторых документов (вернее, генерация документов закупок на основе документов продаж).
Возможно, есть внедрения полноценных распределенных систем на базе других продуктов, но я о них не слышал (в принципе и не очень интересовался). По моему мнению, такие решения сейчас не очень нужны - почти везде можно организовать нормальные каналы связи и работать с централизованной базой, и такой вариант будет удобнее, чем возится с организацией распределенных систем. По крайней мере это справедливо для решений, работающих на реляционных базах данных.
Естественно, это не относится к автономным терминалам сбора данных (кассы и т.п.), время от времени сбрасывающими данные на центральный сервер - такие решения хорошо работают - но с моей точки зрения, это не является распределенными системами.

iscrafm
1. что значит возиться? Определить куда передается информация с узла <> возиться. Обычная настройка, ничем не отличающаяся от других. Выполняется в течении аж 5 минут.
Вы это про 1с или про другую систему?
Если про другую, то не могли бы рассказать чуть подробнее - что за система, и почему была настроена именно как распределенная (на примере какого-либо внедрения)?
Если про 1с, то вот простейший пример - есть сеть магазинов (оптовая торговля). Данные об операциях (продажах) других магазинов в локальном узле быть не должно (требования безопасности), есть только данные об операциях данного магазина. Но в каждом магазине (узле) должны быть данные об остатках на центральном складе и на складах других магазинов. Решение этой задачи занимает далеко не 5 минут. Если у нас имеется 200 узлов, то даже на настройку, куда какая передается информация, уходит много времени - допустим, 5 минут на узел * 200 узлов - это примерно 16 часов - два человеко дня. Именно это и называется возится.
iscrafm
2. Вы связываете необходимость распределенной системы с качеством канала связи, как будто распределенные системы возникли на этой почве. В этом и ошибка. Работать удаленно онлайн с центральной базой конечно можно, если предоставляются комфортные условия для работы и точка является разделом центральной базы.
Насколько я понимаю, причин для создания распределенных решений три:
1. плохие каналы связи
2. ограниченность железа (не в состоянии обрабатывать нужное количество транзакций с приемлемой скоростью)
3. ограничения программной платформы (например, нет возможности использовать несколько ядер/процессоров - нельзя обрабатывать нужное количество транзакций с приемлемой скоростью)
Как мне кажется, сейчас можно решить все три проблемы, разве что для некоторых случаев это нецелесообразно по экономическим причинам (например, слишком дорого переписывать унаследованное ПО).

strizh
1С 8.1 УПП. УРБД. Центральная база + 7 подчиненных баз. Работа в режиме 24*7.
Наработка на отказ для центральной базы составляет в среднем 80 часов. Время восстановления 1 час. 95% отказов в обслуживании - обновления конфигурации УРБД, которые делаются в рабочее время (на это время система блокирована). По-другому, к сожалению, наш отдел 1С не может организовать работу (хотя ситуация за последний год улучшилась немного). Остальные 5% отказов для центральной базы - ошибки после сложных обменов в УРБД.
Наработка на отказ для подчиненных баз составляет в среднем 350 часов. Время восстановления 2 часа (много из-за того что админы в центральном офисе сидят).
strizh, а не могли бы вы указать причину, по которой используете УРБД?
Много пользователей (одна система не справляется) или недостаточно хорошие каналы связи?

У нас режим работы намного более щадящий - примерно 10*6, и статистику никто не ведет (это не критично), так что данные указать не могу...

Last1Cmen

это фантастика... насчет БОЛЬШОГО отдела - не пугайте людей...
при желании ЛЕГКО можно выбрать такую схему, при которой ДЕЙСТВИТЕЛЬНО нужен будет приличный штат для обслуживания 1с.
;-)))