Според моя опит истинският въпрос най-вече се свежда до това дали ще възникне някакво ограничение за достъп, специфично за потребителя.
Да предположим, например, че проектирате схемата на общност и че позволявате на потребителите да превключват видимостта на техния профил.
Една от опциите е да се придържате към флаг за публичен/частен профил и да се придържате към широки, изпреварващи проверки на разрешения:'users.view' (преглежда публични потребители) срещу, да речем, 'users.view_all' (преглежда всички потребители, за модератори) .
Друго включва по-прецизирани разрешения, може да искате те да могат да конфигурират нещата, така че да могат да се направят (а) видими от всички, (b) видими от техните ръчно подбрани приятели, (в) да останат изцяло частни и може би (d ) може да се види от всички, с изключение на техните ръчно подбрани боза. В този случай трябва да съхранявате данни, свързани със собственик/достъп за отделни редове, и ще трябва да абстрахирате някои от тези неща, за да избегнете материализирането на преходното затваряне на плътна, ориентирана графика.
И при двата подхода открих, че допълнителната сложност при редактиране/присвояване на роли се компенсира от произтичащата лекота/гъвкавост при присвояването разрешения за отделни части от данни и че следното работи най-добре:
- Потребителите могат да имат множество роли
- Роли и разрешения, обединени в една и съща таблица с флаг, за да се разграничат двете (полезно при редактиране на роли/разрешения)
- Ролите могат да присвояват други роли, а ролите и разрешенията могат да присвояват разрешения (но разрешенията не могат да присвояват роли) от една и съща таблица.
След това получената ориентирана графика може да бъде изтеглена в две заявки, изградена веднъж завинаги за разумен период от време, използвайки езика, който използвате, и кеширана в Memcache или подобен за последваща употреба.
Оттам нататък изтеглянето на разрешенията на потребителя е въпрос на проверка кои роли има и обработката им с помощта на графиката на разрешенията, за да получите окончателните разрешения. Проверете разрешенията, като проверите дали даден потребител има определената роля/разрешение или не. И след това изпълнете вашата заявка/издаване на грешка въз основа на тази проверка на разрешението.
Можете да разширите проверката за отделни възли (т.е. check_perms($user, 'users.edit', $node) за "може да редактира този възел" срещу check_perms($user, 'users.edit') за „може да редактирате възел“), ако имате нужда, и ще имате нещо много гъвкаво/лесно за използване от крайните потребители.
Както трябва да илюстрира началният пример, внимавайте да насочвате твърде много към разрешения на ниво ред. Тънкото място в производителността е по-малко в проверката на разрешенията на отделен възел, отколкото в изтеглянето на списък с валидни възли (т.е. само тези, които потребителят може да преглежда или редактира). Бих посъветвал нищо извън полетата за флагове и user_id в самите редове, ако не сте (много) добре запознати с оптимизирането на заявки.
