Kontrola dostepu na poziomie zasobow - jak najlepiej przechowywac uprawnienia w bazie?, Kwestia wydajnosci Opcje

[c2h5oh]

Mam zaplanowany mechanizm kontroli dostepu do zasobow w CMSie opierajacy sie na tej samej idei co dostep do plikow w systemach unixowych - grupy + userzy, uprawnienia moga byc przypisane do grupy i do usera, user moze byc czlonkiem dowolnej liczby grup itd.

Problem jak to przechowywac w bazie, zeby byl mozliwy wydajny dostep do tych danych.
poki co mam tabele zawierajace odpowiednio uzyszkodnikow, grupy i przynaleznosc uzyszkodnikow do grup (uzutkownik moze byc w wielu grupach, wielu uzytkownikow moze byc w jednej grupie), do tego tabela zawierajaca zasoby.

Pierwszym rozwiazaniem jakie przychodzi do glowy to 2 dodatkowe tabele - jedna zawierajaca zestaw zasob-uprawnienia-idUprawnien, druga idUsera/idGrupy-idUprawnien, alternatywnie jedna tabela laczace te dwie, ale wtedy niepotrzebnie powielamy uprawnienia. Proste jak budowa cepa i rownie niewydajne co to narzedzie ;-)

To rozwiazanie wydaje sie wiecej niz wystarczajace, gdyby ograniczyc jego stosowanie do mało obciażonego backendu - spadek wydajnosci serwisu jako calosci bylby minimalny. Nie przejdzie jednak, gdyby chciec je zastosowac przy frontendzie i jednoczesnie traktowac publikowane tresci w kategorii zasobu - doszloby za duzo zapytan do bazy.

Co proponujecie jako alternatywe z zachowaniem funkcjonalnosci? Jedyne co dotychczas wymyslilem to sztuczne wydzielenie kilku(nastu) najpopularniejszych grup (anonymous, registered, premium user,..., extra privileges), ktorych uprawnienia beda przechowywane w tabeli zasobow i odwolywanie sie do wczesniej opisanej struktury odbywaloby sie jedynie przy stwierdzeniu usertype == extra privileges.

Czy znacie/mozecie zaproponowac jakies lepsze rozwiazanie?

[php programmer]

hm czy na pewnojest sens tworzenia grup?
bo jeśli liczba osób zarządzających treścią strony
to kilka lub kilkanaście osób, to ja nie widzę sensu tworzenia grup,
a nie sądze żeby było ich więcej.