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?

Hm. Osobiście doszedłem do wniosku, że tak skomplikowany system nie ma sensu. U mnie użytkownik może należeć do jednej grupy, a do grupy przypisujemy prawa.

Co do Twojego problemu to trochę nie do końca go rozumiem jak chodzi o tą wydajność... przecież listę praw powinniśmy zapisać wg mnie do sesji przy logowaniu, więc jest to pojedyncza operacja. Następnie sprawdzasz sprawdzasz jakie wymagania ma dany zasób ... i sprawdzasz z danymi w sesji.

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.

Niestety potrzebuje az takiej swobody i precyzji w definiowaniu uprawnien - uproszczenia, przynajmniej na poziomie backendu, nie wchodza raczej w gre. A w backendzie spodziewam sie ok 75-200 roznych grup, przy czym kazdy z uzytkownikow ze specjalnymi uprawnieniami bedzie nalezal do 5-20 (i dostep do backendu przewidziany dla ok setki).
Nie jestem pewien czy przechowywanie tak rozbudowanej struktury w sesji jest najlepszym pomyslem.

A czy ciebie przypadkiem wyobrażnia za bardzo nie ponosi
Taka Wirtualna Polska ma max kilkadziesiąt osób redagującyh
a ty chcesz mieć około 100 grup po 15 osób

Moze i ponosi albo mysle przyszlosciowo. Na chwile obecna potrzebuje 46 grup (wlasnie policzylem). Poza tym fakt, ze bede mial 100 grup po 15 osob nie oznacza 1500 osob redagujacych, a raczej, ze bede mial np 30 osob, ale z precyzyjnie okreslonymi, jasnymi prawami dostepu.

Ale pominmy kwestie zasadnosci stosowania tak rozbudowanej kontroli dostepu i zalozmy, ze jest jednak konieczna - jak najlepiej to zrobic, zeby bazy nie zabic na smierc?

Nie bądź śmieszny przy takiej ilości danych to nawet SQLite sobie poradzi bez większego problemu , no chyba, że tak mizernie zaprojektujesz bazę .
Najprostszy przykład:

users: id,login,pass
actions: id,name
groups: id,name
actions_in_groups: id,group_id,action_id
users_in_groups: id,user_id,group_id