Witam,
chciałbym zapytać jak to można rozwiązać problem modyfikacji i tworzenia aplikacji (co za tym idzie bazy danych) złożonej z wielu tabel. Załóżmy że mamy około 30 tabel (a co tam), z tego 15 tabel z danymi na których pracujemy ,a pozostałe 15 to informacje o uprawnieniach i użytkownikach. Czy jesteście w stanie sobie wyobrazić 15 tabel opisujacych uprawnienia użytkowników do obiektów + 15 tabel z rekordami reprezentującymi obiekty ! ! ! ..... do tego relacje, zależności, zapytania !
Nawet jeśli ubierzemy to wszystko w obiekty i klasy, to zapytania będą robione przez joinny na kilka tabel (np. pobieramy dane użytkownika. uprawnienia użytkowników,dane objektów,po czym to wszystko sprawdzamy), można to załagodzić widokami co może troche poprawić trochę kod sql w aplikacji.

Czy mamy dwa rozwiązania : budować bazę i pisać wielkie zapytania po czym ubierać to w objekty.... lub pobierać dane prosto do określonych modułów przez proste zapytania i porównywać między modułami (porównywać kolekcje obiektów...takie joiny w php) ?

Dochodzę do wniosku że bez obiektowych baz danych źle to wygląda.

Doszedłem to tego punktu od kiedy pojawiła się potrzeba budowania aplikacji z rozbudowana kontrolą dostępu użytkowników.

Jak wy sobie z tym radzicie ? Zachęcam do dyskusji !

Nie wiem po co ci obiektowe bazy danych. Troche bawiłem sie nimi w Oraclu i uważam że można sobie spokojnie bez nich poradzić. Widziałem wieksze projekty , po kilkaset tabel i jakoś nikt nie panikował
Przenoszenie zadań baz danych do jezyka progamowania to idiotyzm poniważ bazy są do tego żeby łączyć dane, filtrowac i wykonywać proste operacje logiczna matematyczne, są do tego zoptymalizowane a samo myślenie o robieniu tego poza bazą dowodzi że masz chyba małe doświadczenie i powinieneś przyjrzeć się możliwością baz danych. Poza select , insert i update bazy maja ogromne możliwości a cały mechanizm który jest schowany za optymalizacją działania bazy jest nie do "ulepszenia" w żadnym innym miejscu a szczególnie wyciągając ogromne pokłady danych do aplikacji!

A ile z tych kilkuset tablel było odpowiedzialne za przechowywanieinformacji o uprawnieniach.

Mam problem z optymalnym rozwiązaniem tego w swojej aplikacji, działa to mniej więcej tak :
- w aplikacji możemy stworzyć 7 rodzajów obiektów które mają role
- każdy z tych 7 obiektów ma inne grupy uprawnonych (role) które powstają razem z obiektem (dynamicznie)
- każdy z tych obiektów może wybrać rodzaj polityki (jak w Apache)
- każdy z tych obiektów w trakcie nadawnia uprawnień może wykorzystywać powstałe już grupy (role) wcześniej powstałych obiektów

A co się dzieje gdy chcemy wyświetlić listę objektów np. drugiego rodzaju ?
- system sprawdza czy użytkownik ma możliwość pracy z każdym obiektem z listy...
tzn.pobranie ID objektu i jego polityki dostępu, pobranie ID zalogowanego użytkownika, przekazanie tego klasy sprawdzającej w której za każdym razem (dla każdego obiektu z listy) na podstawie wcześniej podanych informacji pobierane są dane o grupach do których należy użytkownik i o grupach które są uprawnione do korzystania z obiektu uwzględanijąc jego politykę dostępu.

Nie jest to zrobione jak w CMSach, zgdzie mamy 5 ról i koniec. Tutaj każdy z obiektów ma inne role, dodatkowo obiekty te są w pewnej hierarchi, gdzie uprawnienia do obiektu o wyższej randze przekazywane są obiektom podległym (dziedziczenie uprawnień).

Starałem się napisać to w najbardziej zrozumiały sposób, i mam wrażenie że nie do końca mi się to udało ale powinno to zarysować wam obraz problemu. Jak rozrysowałem ten system uprawnień za pierwszym razem wydało i się to niemożliwe, teraz mam już to zaimplementowane ale nie podoba mi się sposób w jaki to działa.

Pisał ktoś kiedyś coś takiego ? Jakieś podpowiedzi czy linki ?
Pozdrawiam


edit //
jestem zwolennikiem przechowywania logiki po stronie bazy, przynajmniej pewnej części

nie jestem pewien ale wydaje mi sie ze wystarczyły by Tobie 4 tabele + relacja wiele do wielu.