Поля типов Readers и Authors: одно или много?

[divankin]

Я всегда считал, что нужно максимум одно поле каждого типа. Слышал, что вьюшки дольше открываются, если полей типа Readers больше, чем одно.
При отладке в случае множества полей придется просматривать их все, чтобы определить имеет ли человек доступ к документу.
Считаю, что надежнее при каждом сохранении документа перерасчитывать права доступа в одном поле, чем включать изменение состава некоторых полей Readers/Authors в конкретные действия. Ведь так проще соблюсти принцип минимальной достаточности прав, и не оставлять права редактирования пользователю, когда он не должен редактировать документ.

А что думаете вы по этому поводу?

 

[ToxaRat]

да пофиг собственно
в 8.5 права доступа вообще вынесли отдельно и теперь скоростью вьюшек на это не влияет
тут правильнее сказать что ОБЬЕМ данных в этих полях влияет на скорость, тоесть чем больше ридеров(например у вас там прописано 50 человек) тем труднее открыть док
для дебагинга это как то фиолетово, я привы что для админа у меня свои поля ридерс/авторс, а для обычных юзверей свои

 

[NickProstoNick]

в 8.5 права доступа вообще вынесли отдельно и теперь скоростью вьюшек на это не влияет

А мне всегда казалось что правами рулил сервер.

Divankin, просто часто необходима одним и тем же людям предоставлять права на всех этапах существования документов. по этому проще их вынести поле, которое не будет меняться чем постоянно сортировать одно поле.

тут правильнее сказать что ОБЬЕМ данных в этих полях влияет на скорость, тоесть чем больше ридеров(например у вас там прописано 50 человек) тем труднее открыть

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

 

[ToxaRat]

А мне всегда казалось что правами рулил сервер.

и я про то, чтолько теперь он еще лучше рулит этим

 

[Alexander (Criz)]

ToxaRat
а скиньте, пожалуйста, ссылочку на инфу про новую схему работы -

в 8.5 права доступа вообще вынесли отдельно и теперь скоростью вьюшек на это не влияет

 

[divankin]

Divankin, просто часто необходима одним и тем же людям предоставлять права на всех этапах существования документов. по этому проще их вынести поле, которое не будет меняться чем постоянно сортировать одно поле.

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

 

[ToxaRat]

Alexander (Criz)

а скиньте, пожалуйста, ссылочку на инфу про новую схему работы

не могу найти, мелькало когда-то,
суть начиналась с того, что административные запросы по переименовыванию пользователя теперь выполняются быстрее за счет того что ACL Документа лежит теперь отдельно и по нему легко делать поиск и менять нужные доки

 

[divankin]

не могу найти, мелькало когда-то,
суть начиналась с того, что административные запросы по переименовыванию пользователя теперь выполняются быстрее за счет того что ACL Документа лежит теперь отдельно и по нему легко делать поиск и менять нужные доки

И Names поля тоже лежат отдельно? Переименование пользователя происходит и в полях типа Names тоже.

 

[Medevic]

У меня есть по одному Readers и Authors полю для ролей типа Admin и подобного. Есть много полей типа Names. И есть еще по одному полю Readers и Authors, куда собираются данные из полей Names.
Это в общем случае.

 

[ToxaRat]

И Names поля тоже лежат отдельно? Переименование пользователя происходит и в полях типа Names тоже

нужно искать статью про более шустрое выполнение административных запросов
а лежат ли неймес отдельно я не знаю и как узнать тоже

 

[NickProstoNick]

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

Если у тебя не грамотно организована раздача прав - это твои личные проблемы. И не надо пенять на то что много полей!
Я же тебе говорю, два поля для тех, кому доступ нужен на постоянной основе... т.е. это по одному полю ридерс и авторс;
Ну и еще по одному полю для оперативных целей.Значение этих полей каждый раз вычисляется на каждом новом этапе движения документа. Имена из авторсов добавляются в ридерсы... так же из ридерсов удаляются те, кому уже доступ не нужен, а в авторсы заносятся новые люди/группы. Потому никакой избыточности нет. А по завершению обработки документов надо оставлять только определенные группы людей.
У меня в примеру в конце обработки остается 2 автора. Это люди/группы/роли которым доступ предоставляется на постоянной основе. И до 10 групп в ридерах. Все работает отлично.

Хороший прирост в производительности дает уменьшение количества документов-респонсов

 

[Alexander (Criz)]

более шустрое выполнение административных запросов

Да, про это я читал, я подумал что как-то по другому стало работать открытие видов с имеющимися там документами, в которых есть Readers/Authors поля...

 

[ToxaRat]

Да, про это я читал, я подумал что как-то по другому стало работать открытие видов с имеющимися там документами, в которых есть Readers/Authors поля...

а это косвенно косается всего сразу
ведь по большому счету сервер в виде показывает все документы согласно критериям поиска и лишь потом на момент запроса этого списка для какого-то конкретного пользователя сверяет его со списком видимых лично ему данных - а это и есть обращение в эту таблицу ACL

 

[Akupaka]

Если у тебя не грамотно организована раздача прав - это твои личные проблемы

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

проще их вынести поле, которое не будет меняться чем постоянно сортировать одно поле.

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