Podle mých zkušeností se skutečná otázka většinou rozpadá na to, zda dojde nebo nedojde k nějakému omezení přístupu specifického pro uživatele.
Předpokládejme například, že navrhujete schéma komunity a že umožňujete uživatelům přepínat viditelnost jejich profilu.
Jednou z možností je držet se příznaku veřejného/soukromého profilu a držet se širokých, preventivních kontrol oprávnění:'users.view' (zobrazuje veřejné uživatele) vs, řekněme, 'users.view_all' (zobrazuje všechny uživatele, pro moderátory) .
Další zahrnuje propracovanější oprávnění, možná budete chtít, aby mohli konfigurovat věci tak, aby se mohly (a) zobrazovat všem, (b) zobrazovat jejich ručně vybraným kamarádům, (c) být zcela soukromé a možná (d ) mohou zobrazit všichni kromě jejich ručně vybraných bozos. V tomto případě musíte uložit data související s vlastníkem/přístupem pro jednotlivé řádky a budete muset některé z těchto věcí silně abstrahovat, abyste se vyhnuli zhmotnění tranzitivního uzavření hustého, orientovaného grafu.
U obou přístupů jsem zjistil, že přidaná složitost při úpravách/přiřazování rolí je kompenzována výslednou snadností/pružností při přiřazování oprávnění k jednotlivým datům a že nejlépe fungovalo následující:
- Uživatelé mohou mít více rolí
- Role a oprávnění jsou sloučeny ve stejné tabulce s příznakem pro rozlišení obou (užitečné při úpravách rolí/oprávnění)
- Role mohou přidělovat další role a role a perms mohou přidělovat oprávnění (ale oprávnění nemohou přidělovat role) ze stejné tabulky.
Výsledný orientovaný graf lze poté načíst ve dvou dotazech, vytvořit je jednou provždy v rozumném čase pomocí libovolného jazyka, který používáte, a uložit do mezipaměti Memcache nebo podobného pro další použití.
Odtud je získání oprávnění uživatele otázkou kontroly, které role má, a jejich zpracováním pomocí grafu oprávnění k získání konečných oprávnění. Zkontrolujte oprávnění ověřením, zda má uživatel zadanou roli/oprávnění či nikoli. A poté spusťte dotaz/vydejte chybu na základě této kontroly oprávnění.
Můžete rozšířit kontrolu pro jednotlivé uzly (tj. check_perms($user, 'users.edit', $node) pro "může upravit tento uzel" vs check_perms($user, 'users.edit') pro "může upravit uzel"), pokud to potřebujete, a budete mít něco velmi flexibilního/snadno použitelného pro koncové uživatele.
Jak by měl ilustrovat úvodní příklad, dejte si pozor na přílišné směrování k oprávněním na úrovni řádků. Úzké hrdlo výkonu je menší při kontrole oprávnění jednotlivých uzlů, než při stahování seznamu platných uzlů (tj. pouze těch, které může uživatel zobrazit nebo upravit). Pokud se (velmi) neorientujete v optimalizaci dotazů, nedoporučoval bych nic jiného než příznaky a pole user_id v samotných řádcích.