хранимые процедуры и nested-sets

[desperado]

хранимые процедуры и списки-смежности (adjacency-lists)

собственно есть AccessControList, что-то вроде этого:

Table: ACL
---------------
userRef // foreign key to Users table
resourceRef
accessType // "read-only", etc. Could be made fancier than one field

Table: Users
----------------
userID
name
isGroupOnly // if cannot be an individual

Table: Groups
-----------------
userRef1 // foreign key to Users table
userRef2 // foreign key to Users table

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

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

 

[hermit]

белый писец, белый снег... писец ничего не понятно

какая таблица с какой связывается по ключам?
Насколько я понял, то ACL.userRef -> Users.userID, или же userRef это привязка к группе?

почему для userRef1 и userRef2 написано что они связаны с таблицей Users? Поясни как следует, думаю есть выход из положения

 

[Wicked]

во-первых следует задать вопрос: а причем тут нестед сетс?

 

[desperado]

Table: Users
-------------------------------
userID | name | isGroupOnly
-------------------------------
1 | GROUP_1 | 1
2 | GROUP_2 | 1
3 | GROUP_3 | 1
4 | user_1 | 0
5 | user_2 | 0
6 | user_3 | 0

Table: Groups
-------------------
userRef1 | userRef2
-------------------
2 | 1
3 | 2
4 | 1
5 | 2
6 | 3

или деревом

++GROUP_1
|
+-+GROUP_2
| |
| +-+GROUP_3
| | |
| | +-user_3
| |
| +-user_2
|
+-user_1

про ACL особо подробно говорить не стоит?... там может быть прописано право как для конкретного пользователя (скажем user_1), так и для группы (GROUP_1), тогда все ее потомки будут наследовать права этой группы... вообщем про ACL написно здесь http://www.c2.com/cgi/wiki?AccessControlList и не только

немного переформулирую вопрос первого поста:
у меня нет вопросов касаемо реализации на стороне PHP (если это так можно назвать), вытащить всех потомков для заданной "вершины" (в данном случае это ACL.userRef) попутно сверяя не является ли этот потомок искомым для нас пользователем - не проблема

у меня вопрос - имеет ли смысл реализовывать это с помощью процедуры на мускуле

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

 

[hermit]

фигасе!
а разделять таблицы на просто User и Group не модно уже? нафига и пользователей и группы в одной таблице держать?
Давненько такого не видел!
Ну да ладно, попробуем эти грабли разгрести

 

[desperado]

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

 

[hermit]

Зато появляются проблемы определением прав родителя.
В принципе можно при изменении прав родителя, такие же права ставить и всем его потомкам (писать в таблицу ACM)
Это конечно перегрузка таблицы инфой, зато при определении прав пользователя тебе не прийдется искать права для более верхних уровней, они уже будут видны.
Либо таки рекурсию оставить

 

[desperado]

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

/мда... медленно укатываемся от сути вопроса

-~{}~ 08.06.06 10:20:

кому будет интересно (применительно к мускулю)
http://www.artfulsoftware.com/mysqlbook/sampler/mysqled1ch20.html