Много лотусовых групп для работы БД... это плохо?

[fedotxxl]

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

Соответственно в бд names.nsf придется на каждую роль, департамент создавать документ-группы... На сколько это плохо?

 

[morpheus]

учтите что в ACL базы не потянет более , если не ошибаюсь, 72 групп

имхо, более 20 ролей - это свидетельство неправильной архитектуры

 

[Kee_Keekkenen]

если не ошибаюсь, то групп можно значительно больше чем 72.. скорее всего суммарный объем длин имен групп(а возможно и пользователей) не должен превышать 32к

 

[fedotxxl]

Для: Morpheus
в ACL можно записать всего несколько групп - Authors, Readers и т.д., которые будут содержать все остальные... Другое дело, что правильно ли для работы движка динамически создавать группы в names.nsf?

 

[morpheus]

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

я бы не стал делать такое для баз которые не есть базами отдела кадров ( а значит и Вашей базой пользователей ) , и никак с Отдд.Кадров не связанными

 

[fedotxxl]

Для: Morpheus
Безусловно, трогать АК плохо, но есть несколько НО:

• У меня есть код (который написан, слава богу, не мной), который идеально выполнит функцию добавления пользователя в ACL и ещё многое другое
• Представьте - у вас в движке есть еденица - "ИТ Департамент". Вы явно прописываете в документах всех членов этой единицы... Теперь вы кого-то удалили из "ИТ департамента", кого-то добавили. В этом случае вам нужно будет переконопатить все документы и внести необходимые изменения
• Представьте, что за еденицу "ИТ Департаменты" отвечает группа "MyBase_ITDepartment". При добавлении/удалении членов "ИТ департамента" все что нужно сделать, это добавить/удалить в/из группы. Это и проше, и быстрее в разы. Разве это плохо?

 

[morpheus]

а я и не говорил что это плохо, просто бывают случаи когда к АК Вы просто не имеете доступа ( читатель/автор )

<!--QuoteBegin-fedotxxl+3:01:2008, 00:29 -->
<span class="vbquote">(fedotxxl @ 3:01:2008, 00:29 )</span><!--QuoteEBegin-->Представьте - у вас в движке есть еденица - "ИТ Департамент". Вы явно прописываете в документах всех членов этой единицы... Теперь вы кого-то удалили из "ИТ департамента", кого-то добавили. В этом случае вам нужно будет переконопатить все документы и внести необходимые изменения

[snapback]92096" rel="nofollow" target="_blank[/snapback]​

[/quote]
Вполне нормальный вариант, косяки бывают канечсно при ооочень больших кол-вах людей

 

[oxystile]

можно и без names.nsf обойтись.
Создайте в этой базе документ настроек (Profile) например
или отдельные документы группы (это даже лучше), где укажите имя группы -1-е поле, 2-е поле сотрудники группы.
А поля Readers ваших документов пусть подставляются люди по ключу, где ключ-это имя группы.
Причем, при изменении сотрудников группы пусть запускается код, кот. меняет Readers в документах
(по ключу, где ключ-это имя группы)

names.nsf трогать можно, конечно, но это не совсем верный способ программирования...
(созданные группы должны быть уникальны и полезны не только для одной БД а для многих)

 

[Constantin A Chervonenko]

Счас.. Всем сестрам по серьгам:

Динамически (агентами) модифицировать READERS/AUTHORS поля при изменении состава орг.единиц - разумно только при умеренных объемах базы и низкой интенсивности изменения состава орг.единиц.
В противном случае лучше группы (например как сделано в иТрастовской Компани-Медиа). Большое, с моей точки зрения, НО групп: в мультидоменной среде а).страдает безопасность и б).автоматизированная модификация состава групп усложняется.

Число групп в ACL не ограничено. Скорее ограничен общий объем ACL (64K?). Но тогда группы - экономнее юзер-неймов

 

[K-Fire]

ИМХО, если групп в целом не будет больше какого-то разумного числа (ну допустим до 100-200), то можно так делать и не заморачиваться ничем. Если больше - то надо уже думать, не будет ли такая схема узким местом в производительности приложения.

 

[Guest]

<!--QuoteBegin-Kee_Keekkenen+2:01:2008, 14:23 -->
<span class="vbquote">(Kee_Keekkenen @ 2:01:2008, 14:23 )</span><!--QuoteEBegin-->если не ошибаюсь, то групп можно значительно больше чем 72.. скорее всего суммарный объем длин имен групп(а возможно и пользователей) не должен превышать 32к

[snapback]92038" rel="nofollow" target="_blank[/snapback]​

[/quote]
это ролей можно то ли 70, то ли 72 а группы как раз ограничиваются объемом в 32к (суммарный объем длин имен). там получится около 2000 групп по-моему, все зависит от их названий

 

[morpheus]

Для: Ерюков Алексей
Точно,а то я спутал группы и роли :lol: