Распределенная база данных (УРБД)?????

[ZOOBR]

Приобрели недавно у вас конфигурацию версии 4.55 Prof и сразу столкнулись с некоторыми вопросами!

1) Нам необходимо создать распределенную базу данных. Большинство модулей выгружены во внещние файлы! Я конечно прекрасно понимаю зачем это нужно, но при использовании УРБД мы сразу лишаемся возможности производить автообмен нормальным образом. Так как в процессе работы конфигурацию придется редактировать под наши нужды, придется также гонять все внешние модули по папкам всех переферийных баз!!??? А это явно избыточная операция, да и трафик жрет. Может у вас имеется конфигурация в которой все модули находятся внутри????

2) Также хотелось бы получить хотя бы примерную инструкцию по настройке параметров миграции. С документами все предельно ясно, а вот справочники..... Я хоть и программист, но копатся в таком количестве справочников и выяснять какие же параметры миграции им назначить займет огромное кол-во времени.

3) Параметры миграции должны быть по большей части "Место создания и центр". Как в таком случае произвести наполнение переферийных баз первичной информацией (Справочники констант, свойств и др.).

4) И еще один момент. В вашей конфигурации присутствует только один набор прав. Неплохо было бы сделать еще парочку(Пользователь, Гость). А то при раздаче прав тоже много нюансов возникает.

Заранее благодарю за возможную помощь!

[support]

1. Наверное не большинство а практически все. Тут прийдется делать скрипт для обновлению. Конфигурации которая бы содержала в себе все файлы нет. Обновлять каждый раз внешние модули не имеет смысла поэтому трафик тут не тратится.

2. По справочникам можно сделать полную миграцию если не уверены. Хуже скорее всего не будет, хотя конечно вся информация будет доступна в переферийных базах.

3. А при выгрузке новой периферийной базы разве она пустая? Сначала наверное нужно все настроить в периферийной а потом делать базы.

4. Тут вопрос достаточно сложный. Предложите какие права должны быть у того или другого, я реализую их, но все равно на каждом предприятии это какие то свои ограничения, и они должны все таки настраиватся на уровне предприятия, и в будущем это планируется сделать.


По поводу механизма миграции в 7.7, если честно то поставили меня в тупик, дело в том что я решал недавно тот же вопрос в 8.1 и решение было следуещее, прямо в предприятии настраивался механизм обмена между точками.

Правила обмена могли содержать условия например такие: если подразделение документа ... входит в группу Администрация то будем пересылать этот документ в точки А и Б, и не пересылать в точку С.

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

Планируется реализовать вышеописанный механизм для версии под 8.1, для версии 7.7 он вероятно не появится по причине некоторых ограничений платформы (конечно сделать все равно можно, но уже сложнее)

[ZOOBR]

1. Наверное не большинство а практически все. Тут прийдется делать скрипт для обновлению. Конфигурации которая бы содержала в себе все файлы нет. Обновлять каждый раз внешние модули не имеет смысла поэтому трафик тут не тратится.

А может у вас все-таки имеется версия, где все внешние модули включены в конфигурацию? Писать свою программу для автообмена не очень хочется.

2. По справочникам можно сделать полную миграцию если не уверены. Хуже скорее всего не будет, хотя конечно вся информация будет доступна в переферийных базах.

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

3. А при выгрузке новой периферийной базы разве она пустая? Сначала наверное нужно все настроить в периферийной а потом делать базы.

Не пустая если в параметрах миграции указано "Все информационные базы". А это как я уже сказал выше не подходит.

4. Тут вопрос достаточно сложный. Предложите какие права должны быть у того или другого, я реализую их, но все равно на каждом предприятии это какие то свои ограничения, и они должны все таки настраиватся на уровне предприятия, и в будущем это планируется сделать.

На мой взгляд должны быть следующие права:
Администратор - полный доступ.
Пользователь - доступ для ввода документов и редактирования справочников.
Гость - только просмотр журналов, справочников и документов.

Также не нужно забывать, что для каждого набора прав должен быть свой интерфейс.

Такой механизм прав и интерфейсов подойдет большинству пользователей вашей программы!

Правила обмена могли содержать условия например такие: если подразделение документа ... входит в группу Администрация то будем пересылать этот документ в точки А и Б, и не пересылать в точку С.

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

В принципе главное здесь это не автообмен, а механизм распределения доступа к данным программы. Если например сделать отбор в журналах и справочниках по пользователю, тогда каждый пользователь видел бы и вводил только то что ему разрешено. Суть то вся в том, что при выборе параметра миграции "Место создания и центр" возникает следующая проблема. В центральной базе вносят документ, который должен попасть в периферийную базу, а текущие параметры миграции этого сделать не позволяют! Исправить этот недостаток можно с помощью добавления некого справочника "Автообмен" в который в токой ситуации будет записыватся документ и при следующем запуске периферийной базы, производится проверка на некий реквизит "База", который содержит идентификатор периферийной базы. Если он совпадает с текущей базой, тогда документ загружается из справочника и затем удаляется.

Кстати можно было бы сделать специальный релиз программы, предназначенный для работы с УРБД(цена тоже была бы другой )

[support]

1. Конфигурации в которой все модули включены нет. И включить их достаточно сложно в связи с использованием некоторых механизмов. Например используется несколько внешних компонент, а так же модулей которые грузятся этими внешними компонентами.

2. Описания справочников тоже нет. Если хотите я могу те из них предназначение которых сразу не ясно описать для вас.

3. Ну тогда делайте миграцию все информационные базы. Потом делайте периферийные базы потом меняйте миграцию на место создания и центр.

4. Хорошо запишу себе в будущем сделаю эти права.

--------------------------------------------------------------------

Доступ это отдельная проблема, в конфигурации он не очень хорошо сделан, потому как считаю что делать его стандартными мехнизмами неправильно, в нем нет управления доступом по записям таблиц, он только рулит доступом на уровне таблиц. Но в общем то редко бывает что у конфигурации очень много пользователей поэтому такая проблема редко встает.

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