наутилус
а потом заказчик скажет% "а есть у нас один единственный филиал где работает человек А+В и второй человек С. Так вот первому надо всё в одной "оболочке-программе", а не в двух"...
по мне лучше закладывать избыточность, тем более самый весомый аргумент, это

а ты заказчика спроси:
"Есть функциональное рабочее место ТестовыйРедакторWord.exe и ТабличныйРедакторExcell.exe". Желаете вы иметь для вашего А + В ВСЁ ЭТО в одном флаконе?"

locky по вашему неудобно работать в 1С "Торговля и склад" и 1С "Кадры" и нужно написать :
1С: ТорговляИсклад_Кадры_Бухгалтерия_Производство_..........
?


______________________________________________
Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде!

locky
- точка соприкосновения в 1С - Импорт, экспорт в XML

Как вы объясниет заказчику, что для изменения налоговой политики для бухгалтера в программе Бухгалтерия_Кадры_Склад.exe необходимо купить новую версию "всего самолёта"-exe.

Вопрос архитектуры под Рабочие места (функциональные ! ) не так прост как кажется. ______________________________________________
Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде!

locky
А вот это - половые трудности разработчика, который ЛОГИКУ процессов
зашил в тело программы, а не в, скажем, настройки.

это вы зря
- бизнес-логика и настройки - разные вещи.

наутилус
теория говорит - ДУМАЙ ШИРЕ (набери себе всё сколько можешь унести сейчас и сколько мог бы завтра)

практика говорит - есть другое решение ПРОЩЕ И ПРАКТИЧНЕЕ
Никому не придёт в голову обединять модуль Excel и Word, Кадры и Бух, Склад и Расчёт зарплаты.

"Сложнее всего в мире достигнуть простоты - это крайняя граница опыта и последнее усилие гения". George Sand.

авторзакладывать избыточности (при совсем небольших напрягах разработчика),
уверяю Вас, если вы не пишите программы, что при наличии общих библиотек в папке ..\\Общие_компонеты
сделать 2, 3, 5 проектов - рабочих мест-exe не так трудно.
Следовательно, если пользователь купил ТиС вер.2.0 и Бух.3.5, то обновлять он может их раздельно и за деньги.

Только не надо мне объяснять, что можно обновить только одну DLL-компонет и у Вас станет приложение - ТиС_Бух вер.2.0_4.5.exe

______________________________________________
Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде!

наутилуспо-моему они работают в одном ключе и с одной информацией и разделять их не имеет смысла (имхо).
======= вот и хотел я поболее убедительности в разделении рабочих мест. Что считать функционально разными местами.

у меня вот раньше была программа для работы сервисного центра. и в первоначальной программе (сделаной не мной) так и было. рабочее место - отдельный ехе-файл. так вышло так, что утомительно было дописав в одном месте что-либо вылавливать где и что ещё нужно дописать.
сейчас всё единым файлом сделано, но модульно и человек на "рабочем месте" видит только то, что ему позволено делать. и не может быть просмотр_склада_v1_0, а выписка_со_склада_v2_0. если изменения касаются одного поля, то оно происходит во всех модулях, где нужно.
ите ещё одну копию !!!

====== странные вы, если изменения в БД, то они будут изменяться во всех клиентах независимо от рабочих мест. А вот если вы разбили работу ОДНОГО человека на 2 проги, то ваша проблема, т.к. это ОДНО рабочее место - ОДИН ЛОГИН.

При работе человека А+Б в одном лице, он всё равно должен разлогинится и залогинится под лицом B !!!!! Т.е. если вы в одной проге то выйдете из ней или запуст

!!! Petro123При работе человека А+Б в одном лице, он всё равно должен разлогинится и залогинится под лицом B !!!!!Интересное мнение. Про разграничение прав доступа на уровне групп пользователей никогда не слышали?
наконец дошли до практики.
Я говорю Рабочее_место_руковолителя (РмР) это группа(роль) Руководитель (Р).

Я говорю Рабочее_место_оператора_ЭВМ (РмО) это группа(роль) Оператор (О).
...................
IMHO нельзя без проектирования или переписывания программы писать программу РмР_РмО_Рм?.exe в одном флаконе.
Есть много минусов, и я их перечислял.

Т.е. если пользователь Маша станет одновременно и Руководителем и Операционистом и назначит для себя 2 роли в БД, то на клиенте автоматом не станет удобно и просто работать .
Даже если в меню появятся пункты:
- добавить ФИО нового сотрудника
- Провести анализ хозяйственной деятельности предприятия.

Я уж не говорю про безопасность продажи программы Всё в одном для отдела заказов в урюпинске.

наутилус Petro123IMHO нельзя без проектирования или переписывания программы писать программу РмР_РмО_Рм?.exe в одном флаконе.
не понял. проектирования или переписывания всё-таки? или вы имете ввиду существующую программу и её доработку?
========= Есть такое понятие "Индуктивный интерфейс", когда пользователю предлагаются действия исходя из его обязанностей. Обычно слева полоса с вероятными действиями, или по другому как.
Считаю это хорошим делом для понятности программы (по ISO 9126). Вот это заранее для вашего A+B+C+D не сделать, а если сделать то либо дорого, либо долго.
Petro123Т.е. если пользователь Маша станет одновременно и Руководителем и Операционистом и назначит для себя 2 роли в БД, то на клиенте автоматом не станет удобно и просто работать .
не зарекайтесь. всё зависит от реализации. если ей (по вашей логике) удобно работать в программе а и в программе б, то почему удобства нельзя достигнуть в программе с=а+б
========== см.выше т.к. винигред из команд будет

Petro123Даже если в меню появятся пункты:
- добавить ФИО нового сотрудника
- Провести анализ хозяйственной деятельности предприятия.

Я уж не говорю про безопасность продажи программы Всё в одном для отдела заказов в урюпинске.
как улучшится безопасность если РЕАЛЬНО в юрюпинске вместо 10 человек (бухгалтер+кассир+ещё_один_кассир+кладовщик+директор+отгрузка+просто_менеджер_вася) работает ОДИН мастер_на_все_руки_за_зарплату_нормальную_для_урюписка
=========
1С для этого специально пишет: "Комплексная упрощённая конфигупация" !

или вы предлагаете писать каждый раз под разное колличество мест проги?
т.е. если сегодня у меня на фирме 10 функциональных АРМов (рабочих мест), а работников 3 (ну семирукие они.. успевают совмещать обязаности).. и по прошествии полугода я таки раскошеливаюсь на ещё 5-ых работников, то следуя вашей логике я должен купить у вас новую программу?

10 функциональных АРМов - это 10 непересекающихся функциональных обязанностей. Работнику фиолетово - открыто у него 3 окна a.exe, b.exe, c.exe или 3 окна a_b_c.exe. Посмотрите Word 2003 там вместо одного процесса и 3-х окон на каждый документ открывается 3 процесса.

Просто когда пишется клиент к БД, то IMHO рабочее место соответствует Роли в БД, и вам либо надо будет админить роли в БД для ваших A+B либо заставлять пользователя перелогиниваться - выходить из программы.

Estets
вы забыли поставить OR или AND в требованиях.
Есть заказчик, который говорит:
- я хочу кофемолку и соковыжималку.

OR Есть заказчик, который говорит:
- я хочу кофемолку и соковыжималку в одном флаконе (комбайн тобишь).

Или вы изначально проектируете комбайны, т.к. это
- проще/лучше_покупателю/меньше пласмассы уйдёт/........

авторКакие варианты встречаются:
1) Самый простой, 1 человек "сам себе контролер", сам вносит сам подтвердает
2) Два человека, один оператор только вносит, другой контролер - только подтверждает.
3) "4глаза" два человека, оба могут вносить документы, но подтверждать могут только чужие документы. 1-ый акцептует документы второго, и наоборот.

Вопрос как это можно разделить в рамках разных приложений?
если в БД с правами проще - комбинируй как тебе надо, то на клиенте так просто не получится.
У заказчика надо спросить или аналитику выяснить - пишем трансформер людей-глаз-пароходов-контроллёров или ......
например пишем одну Большую кнопку "Акцепт_того_кто_нажмёт".

IMHO пример не жизненный.
______________________________________________
Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде!

я понимаю, откуда ноги растут.
Если рассуждать с точки зрения разработчика БД, то всё просто:
- в БД на каждый объект права и роли
- на клиенте Большая таблица и кнопка "отправить SQL текст".
Тогда конечно - оптимальный вариант - одно приложение на сколько угодно рабочих мест, т.к. тебе просто придёт сообщение на DELETE.... - "У вас нет прав на это, следовательно Вы - дворник!"

К сожалению трансформация рабочего места (разнообразный интерфейс под функционал) для клиента проблематична. У всех разные таблицы-компонеты-кнопки-графики-ползунки для аналитики и т.д.

Поэтому IMHO оптимально писать одно, а рационально писать другое.
______________________________________________
Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде!

Estets
Это все я к тому что практически любое "реальное внедрение", программного продукта очень быстро заставит забыть о понятии рабочего места как
"Есть директор, есть дворник и ничего общего у них нет".
============= т.е. это не проектируется в виде схем/диаграмм/ВИ (это не то?). Всё таки ветка форума о грамотном проектировании БД.
На самом деле есть пять сотрудников отдела, которые имеют одни и те же права и обязанности, но 1-ый может еще и подписывать счета, 2-ой и 3-тий могут форимровать квартальную отчетность, 4-ый готовит файлики с проводнами для загрузки в 1С, а пятый имеет права на сторнирование операций.
====== если права ОДНИ И ТЕ ЖЕ, то и говорить не о чем - это всё одно рабочее место.
Я говорю о рабочем месте, когда группа_руководство говорит: "вход по логину, и всё что я вижу не должен видеть кладовщик".