Aplikacja typu saas - architektura Opcje

[tczajka]

Witam wszystkich.
Zaczynam pracę nad projektowaniem i pisaniem pewnej aplikacji w modelu saas gdzie przewiduję takie mniej więcej elementy:
- panel admin najwyższego rzędu gdzie będą zakładane/generowane konta klientów w skład których będa wchodzić poniższe części:
- panel admin (klienta) dla zarządzania bazą użytkowników, przydzielaniem usług, definiowaniem usług itp (wszystko w ramach jednego klienta)
- panel usera do zarządzania i do-konfigurowania przez usera założonego na poziomie wyżej
- strona usera do prezentacji treści usera (np konkretnych usług oferowanych przez usera-klienta)
Przykładem może tu być aplikacja do zarządzania hurtowniami gdzie zakładamy konta np dla Hurtowni 1, Hurtowni 2 itpp. W nich tworzeni są konta dla pracowników do zarządzania ofertą itp.

Zastanawiam się tutaj nad 3 możliwościami:
1. Tworzyć wszystko na jednym adresie, jednej bazie danych (jeden handler dla wszystkich kont) i ograniczać dostęp do poszczególnych danych odpowiednio implementując system autoryzacji itp
2. Tworzyć wszystko na jednym adresie , ale każdy klient będzie na osobnej bazie danych separując tym samym dane jednego klienta od drugiego (istotne w razie włamu)
3. Tworzyć osobną aplikację do admina adminów np na innym adresie (gdzie będą zakładani Ci duzi klienci, np hurtownie), oraz osobną dla klientów (tutaj to samo jak wyżej albo na jednej bazie wszyscy klienci albo każdy na osobnej)

Podział na osobne bazy danych rodzi tylko więcej roboty z zakładaniem kont (jakiś manager handlerów do DB). Z założenia nie będzie tam dziur ale moje rozważania wynikają głównie z obawy że podczas włamu atakujący dostanie dostęp do wszystkich klientów, podczas gdy gdyby każdy klient był na osobnej bazie szkody mogą zostać ograniczone.

Co o tym sądzicie? Które rozwiązanie wg Was jest lepsze i dlaczego lub dlaczego nie? Inne rozwiązanie?
pozdrawiam

[nrm]

Kumam. I podtrzymuje swoja opinię: gdybym ja to robił i miał podobne wymagania j.w. opisane to prawdopodobnie nie łądowałbym się w osobne bazy per klient. Także nie zgadzam się z punktami wad:
1. - nie widzę żadnego problemu w posiadaniu "rożnych ficzerów per klient",
2 - nie do końca rozumiem,
3 - nie trzeba żadnych kolumn, wystarczy w konfigu mieć zapisane do czego dany klient ma dostęp, to tak jakby twierdzić, że trzeba miec osobne bazy dla klientów z abonamentem1, abo 2 czy abo 3 (IMG:style_emoticons/default/wink.gif)
4 - taka wada trochę na siłę wszak róznego rodzaju "przerwy techniczne" są nieuniknione bez względu na rozwiązania bazowe i dotyczą wszelkich mozliwych warstw (od serwerowych po aplikacyjne).

To wszystko co teraz wymienił @tczajka to jest dla mnie jeden projekt, jedna aplikacja, dla mnie nie ma znaczenia, że ona ma częśc do zarządzania głównymi klientami, a ci z kolei jako klienci zarządzają swoim kurnikiem. Obojętne mi to (IMG:style_emoticons/default/wink.gif) To jakby podzielić Wordpressa MU (tego wieloinstancyjnego) na kilka części ze względu na zastosowanie (IMG:style_emoticons/default/wink.gif)

----

Podam wam przykład jednego SaaSa, który generuje nam kosmiczne ilości danych. Klient w nim może mieć podużytkowników z dostępem (ustawia jak daleko idącym), aplikacja zbiera pewne dane, w ogromnych ilościach. Są one rozdzielone na kilka baz z kluczem "pewien typ danych - osobna baza". Każdy klient ma do wyboru co zbiera więc można powiedzieć, że nie wiemy ile i jakie komponenty wybierze - wybiera co mu pasuje. Stąd jedne bazy zapełniają się szybciej, inne wolniej - w zależności od popularności danego komponentu.