Dylemat dot. budowy aplikacji - jedna aplikacja - wiele baz danych

Jestem w trakcie tworzenia aplikacji webowej (MVC 3, SQL SERVER 2008 r2, entity framework CF) i mam dylemat dotyczący jej budowy. Aplikacja będzie płatna, nie będzie z niej korzystać więcej niż 1tys użytkowników (około 20-30 tabel w bazie danych, max 20000 rekordów w każdej tabeli na użytkownika). Wszyscy użytkownicy będą korzystać z jednej fizycznej aplikacji on-line, ale każdy użytkownik to wydzielone (prywatne) informacje, niewidoczne dla innych.
I tu rodzą mi się 2 rozwiązania (ale nie wiem, które wybrać ;) )
**Rozwiązanie 1: **
Jedna baza dla wszystkich klientów, gdzie każdy obiekt będzie w relacji z id właściciela.
**Rozwiązanie 2: **

• Głowna baza trzymająca tylko tabele niezbędne do zidentyfikowania użytkownika (aspnet_Membership itd) i informację na temat bazy z z jaką jest powiązany użytkownik + oddzielna baza dla każdego klienta, w której trzymana jest reszta tabel.

Tak

Nie widzę sensu w dublowaniu baz danych. Uzasadnij.

Przypomina mi się pewna firma, w której pracował mój kolega... Zbudowali bardzo oryginalnego, autorskiego cmsa. Jego wyjątkowość polegała na tym, że dla każdego użytkownika tworzyli w bazie oddzielne tabele, zaczynające swą nazwę nazwiskiem klienta. Komentarz mam jeden - co to za potwór :O

Dublowanie baz danych nie brzmi co prawda aż tak głupio, jak to powyżej, ale mimo wszystko jest to redundancja. Redundancja jest zła. Rzadko kiedy uzasadniona. Potrafisz ją uzasadnić w tym wypadku?

Oczywiście problemem jest duplikowanie struktury bazy i później ewentualna aktualizacja. Przewagą jest mniej problematyczne przejście na dedykowaną aplikacje (jeśli użytkownik będzie przekraczał limity) i mniejsza różnica przy rozwijaniu dwóch wersji oraz brak konieczności odpytywania za każdym razem BD o właściciela obiektu.

brak konieczności odpytywania za każdym razem BD o właściciela obiektu.

Hm, hasło na dziś: sesja.

Przewagą jest mniej problematyczne przejście na dedykowaną aplikacje (jeśli użytkownik będzie przekraczał limity)

.....czyli porzucenie baz danych celem przejścia na dedykowaną aplikację? Przyznam, że kompletnie nie rozumiem, o co chodzi w tym zdaniu.
Kiedy użytkownik przekracza jakieś "limity", to się poprawia architekturę aplikacji, a nie multiplikuje bazy danych.

mniejsza różnica przy rozwijaniu dwóch wersji

Oj, chłopie, już widzę ten pierdyliard baz.... dla każdego użytkownika * liczba wersji.

IMHO, powściągnij swe zapędy, twe uzasadnienie dla nich nie jest specjalnie przekonujące.

aurel napisał(a):

brak konieczności odpytywania za każdym razem BD o właściciela obiektu.

Hm, hasło na dziś: sesja.

Nie chodzi mi o przechowywanie id klienta, a sprawdzanie, czy odpytujący o konkretny obiekt user jest faktycznie jego "właścicielem".

Przewagą jest mniej problematyczne przejście na dedykowaną aplikacje (jeśli użytkownik będzie przekraczał limity)
.....czyli porzucenie baz danych celem przejścia na dedykowaną aplikację? Przyznam, że kompletnie nie rozumiem, o co chodzi w tym zdaniu.
Kiedy użytkownik przekracza jakieś "limity", to się poprawia architekturę aplikacji, a nie multiplikuje bazy danych.

Limity to parametry określone w wykupionym pakiecie - np. ilość produktów, itp. Dedykowana aplikacja, to np. aplikacja na serwerze klienta.

akob7 napisał(a):

Limity to parametry określone w wykupionym pakiecie - np. ilość produktów, itp.

Więc jeśli count * from Produkty będzie równe limitowi, to nie pozwalasz klientowi zapisać nowego i informujesz go, że powinien kupić większy pakiet.

Dedykowana aplikacja, to np. aplikacja na serwerze klienta.

W takim przypadku wystarczy utworzyć bazę na serwerze klienta, i skopiować do niej wszystkie dane z pierwotnej bazy. To taki problem?

Popieram, tworzenie wielu baz danych nie ma raczej sensu. Spotkasz się z wieloma problemami przy utrzymywaniu wszystkiego w kupie. Np. musisz mieć dodatkową bazę na jakieś ustawienia stałe np. konfigurację, produkty (które są widoczne dla wszystkich itd). Co w sytuacji, gdy będziesz chciał zliczyć wszystkie zamówienia wszystkich użytkowników, które zostały dodane po 2013 roku ? Co w sytuacji, gdy będziesz potrzebował dołożyć kolumnę w tabeli zamówienia klienta? Oczywiście da się to zrobić pobierając definicję baz danych z serwera SQL, a następnie w kursorze tworzyć dynamiczne zapytania SQL dodające kolumnę, ale... po co?

A ja się wtrącę troszkę, ale zgodnie z tym co napisali poprzednicy.
Ok 1k użytkowników, około 20-30 tabel. Załóżmy, że tylko 20 jest "specyficznych" dla użytkownika, tj. przechowują dane, które mają być widoczne tylko przez niego. To daje ci 20 tysięcy tabel... tak, dwadzieścia tysięcy. To się nazywa wyzwanie dla bazy danych...
Dodatkowo, zakładam, że nie wszyscy użytkownicy są znani w momencie startu projektu. Dodatkowo zakładaniem użytkowników nie będziesz zajmował się ty, ani pewnie nie będzie tego robił żaden administrator bazy. To oznacza konieczność pisania kodu, który będzie zakładał nowe tabelki za każdym razem, gdy pojawi się nowy użytkownik. Generalnie - masakra. Nie idź tą drogą, w systemie nad którym pracuje mamy na dużo mniejszą skalę dynamiczne zakładanie tabel i wierz mi, nie chcesz tego robić na taką skalę jak planujesz. Dodatkowo, jak w toku działania systemu okaże się, że potrzeba 21 tabelki, to będziesz pisał dynamiczny skrypt, który doda tabelkę tyle razy ile już jest użytkowników, w efekcie czego proste zadania zarządzania bazą będą zajmowały 80% czasu developmentu.

No i pozostaje kwestia bezpieczeństwa. Czy każdy użytkownik aplikacji będzie miał automatycznie tworzone konto użytkownika w bazie danych? Bo chyba nie będzie jednego konta dla wszystkich użytkowników z uprawnieniami do tworzenia nowych tabel, skoro wystarczyłby tylko odczyt i zapis danych.

to na 4p każdy użytkownik nie ma swojej własnej tabeli z danymi, obserwowanymi wątkami itd???? I to działa!?!?