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

fedotxxl

Well-known member
09.11.2005
614
0
#1
Требуется реализовать в движке механизм внутренних ролей, департаметов, рабочих групп и т.д...
Соответственно, чтобы не записывать всех людей из департамента явно в Readers поле, например, я бы хотел писать туда группу, которая будет отвечать за деп... а в случае удаления/добавления пользователя в департамент просто удалять/добавлять пользователя из/в группы(у)

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

morpheus

скриптописец
07.08.2006
3 915
1
#2
учтите что в ACL базы не потянет более , если не ошибаюсь, 72 групп

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

Kee_Keekkenen

Well-known member
05.09.2006
639
4
#3
если не ошибаюсь, то групп можно значительно больше чем 72.. скорее всего суммарный объем длин имен групп(а возможно и пользователей) не должен превышать 32к
 

fedotxxl

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

morpheus

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

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

fedotxxl

Well-known member
09.11.2005
614
0
#6
Для: Morpheus
Безусловно, трогать АК плохо, но есть несколько НО:
  • У меня есть код (который написан, слава богу, не мной), который идеально выполнит функцию добавления пользователя в ACL и ещё многое другое
  • Представьте - у вас в движке есть еденица - "ИТ Департамент". Вы явно прописываете в документах всех членов этой единицы... Теперь вы кого-то удалили из "ИТ департамента", кого-то добавили. В этом случае вам нужно будет переконопатить все документы и внести необходимые изменения
  • Представьте, что за еденицу "ИТ Департаменты" отвечает группа "MyBase_ITDepartment". При добавлении/удалении членов "ИТ департамента" все что нужно сделать, это добавить/удалить в/из группы. Это и проше, и быстрее в разы. Разве это плохо?
 

morpheus

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

<!--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]
Вполне нормальный вариант, косяки бывают канечсно при ооочень больших кол-вах людей
 
O

oxystile

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

names.nsf трогать можно, конечно, но это не совсем верный способ программирования...
(созданные группы должны быть уникальны и полезны не только для одной БД а для многих)
 
30.05.2006
1 345
11
#9
Счас.. Всем сестрам по серьгам:

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

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

K-Fire

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

Guest

#11
<!--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

скриптописец
07.08.2006
3 915
1
#12
Для: Ерюков Алексей
Точно,а то я спутал группы и роли :lol: