Dwa rodzaje użytkowników dwie tabele ? Opcje

[cornholio666]

Witam,

są dwa rodzaje użytkowników, powiedzmy zwykły użytkownik i użytkownik będący prawnikiem. Łączą ich wspólne cechy jak login, hasło, mail itp. Dodatkowo prawnik ma cechy których nie posiada zwykły user np. imię i nazwisko, zwykły user posługuje się nickiem.

Jedna tabela czy dwie na przechowywanie informacji o uzytkownikach? Jakie za jakie przeciw do każdego z rozwiązań ?

[cool_solar]

Argumentem za może być zachowanie porządku w bazie, czyli jedna tabela z pracownikami, ze wskazaniem rodzaju użytkownika i dodatkowymi cechami. Przy takiej konstrukcji zawsze bez zbędnego łączenia tabel czy przeszukiwania dwóch będzie można realizować dowolne zadania.

[Piniek]

ja bym zrobil jedną tabelę i poporstu pola imie i nazwisko ustawil domyslnie null

[cornholio666]

Jakie są minusy przechowywania tych informacji w jednej tabeli ? Czy wpływa to jakoś na wydajność serwisu przy założeniu że liczba użytkowników przekroczy np. 100 000 ?

Czy są jakieś minusy przechowywania tych informacji w dwóch tabelach oprócz konieczności ich złączenia ?

[Piniek]

mysle ze najwazniejsze jest to ze dlugosc wykonyania zapytan do bazy na jednej tablei jest krotsze niz na dwoch

[AxZx]

to chyba zalezy od tego ilu jest uzytkownikow zwyklych a ile prawnikow ktorzy beda mieli wypelnione dodatkowe pola. jezeli wiecej bedzie zwyklych uzytkownikow wtedy duzo kolumn bedzie pustych. jeszcze sie zastanow nad tym jak czesto bedziesz korzystal z dodatkowych pol.

[woj_tas]

mysle ze najwazniejsze jest to ze dlugosc wykonyania zapytan do bazy na jednej tablei jest krotsze niz na dwoch

Bzdura. Dobrze założone klucze i indeksy i nie ma różnicy podczas pobierania danych (a jak jest to bardzo! niewielka).

Zdecydowanie jestem za rozdzieleniem danych na dwie tabele.

[Piniek]

to chyba zalezy od tego ilu jest uzytkownikow zwyklych a ile prawnikow ktorzy beda mieli wypelnione dodatkowe pola. jezeli wiecej bedzie zwyklych uzytkownikow wtedy duzo kolumn bedzie pustych. jeszcze sie zastanow nad tym jak czesto bedziesz korzystal z dodatkowych pol.

a ja po głepszym przemysleniu sprawy przyznam wam jednak racje, ale jak w zacytowanym fragmecie ma znacznie ile bedzie zwyklych userów itych prawników ;p

[AxZx]

no przeciez ci napisalem.

zalozmy ze masz 1000 zwyklych userow i 2 prawnikow.
w takim przypadku tworzac w jednej tabeli dodatkowe kolumny ktore beda wykorzystane tylko dla 2 uzytkownikow jest bezsensem.

ja jestem za rozdzieleniem kolumn - bardziej elastyczne rozwiazanie.

[nospor]

odświerzę troche temat.

Sytuacja: dużo użytkownikow (dużo pojęcie względne, powiedzmy powyżej 100tys.)
Każdy uzytkownik ma podstawowe pola:
imie
nazwisko
login
email
jakies jeszcze ze dwa

oraz dodatkowe pola (powiedzmy kilkanascie, no max 20-30):
czy zezwala na cos x 5
czy zezwala na cos innego x 4
czy cos tam jeszczze x5
jakas opisówka
jakas inna opisówka

I teraz pytanie: dzielić na te dwie tabele czy nie? W zasadzie każde zapytanie, może poza nielicznymi, będzie w zasadzie biegać do dwóch tabel, bo w kazdej bedzie cos waznego. Z tej drugiej tabeli będą wazne te pola "zezwalajace". I powiem szczerze - motam się. Niby zawsze robiłem na jednej tabeli. Unikamy dzieki temu tych nieszczesnych łączen. No ale może jakiś konkretny pożytek z tego podzialu będzie?

[batman]

Też miałem podobny problem i zbadałem go empirycznie
Mam tabele: tabuser i tabprofil. W pierwszej trzymam login, hasło, aktywny, data założenia konta itp. Druga tabela jest tabelą zawierającą specyficzne dla danego systemu dane, np imię i nazwisko, adres, zawód, wykształcenie, pola konfiguracyjne (coś zezwala) itd. Na podstawie tych dwóch tabel mam stworzony widok. Oczywistym jest, że na odpowiednich kolumnach pozakładane mam indeksy.

Wady:
- wolniejsze niż jedna tabela (ale nieznacznie, używając cache-owania nie ma różnicy)
- brak możliwości bezpośredniej edycji danych w widoku (trzeba modyfikować osobno tabuser i tabprofile)

Zalety:
- podczas synchronizacji bazy użytkowników nie muszę się martwić o pola których nie ma / które są w różnych bazach
- przenoszenie kont między systemami (np terminarz, sklep, poczta, itd) sprowadza się do przeniesienia danych z jednej tabeli oraz wszystkiego tego co można z drugiej. Jeśli czegoś brakuje, to zanim przeniesiony użytkownik będzie mógł korzystać z nowego serwisu, musi uzupełnić dane.

[bamboo]

Ja zrobiłbym tabele ze WSZYSTKIMI użytkownikami a na końcu dodałbym pole oznaczające czy dana osoba jest przykładowo tym prawnikiem (np. 0 - uzytkownik normalny, 1 - osoba z wiekszymi uprawnieniami). Utworzyłbym drugą tabele w której indeksem bylyby numery id uzytkowników którzy mają wieksze uprawnienia i własnie w tej tabeli utworzylbym dodatkowe pola które są w tym przypadku potrzebne... Według mnie takie rozwiązanie jest dobre, ponieważ nie bedą sie marnowac pola w bazie ze wszystkimi userami ltórem te dodatkowe dane są zbędne... Dodatkowo ten sposób jest uniwersalny na wszelkiego typu dodatkowe informacje o użytkowniku, administratorze, Vipie czy moderatorze (2, 4, 5 itd.), np. przwileje, uprawnienia i inne dodatkowe pola.

[nospor]

Według mnie takie rozwiązanie jest dobre, ponieważ nie bedą sie marnowac pola w bazie ze wszystkimi userami ltórem te dodatkowe dane są zbędne...

Rozmawiamy teraz o opcji numer dwa - nie ma zbednych pol. kazdy user bedzie mial wypelnione wszystkie pola.
I prosilbym o wypowiedź osób co to juz robily i mają doswiadczenie z tym

@batman dzieki. Mowiac "widok" masz na mysli widok mysql? powiedzmy ze wolalbym uniknac tworzenia widoków

[teutates]

Jestem za rodzieleniem userow. Skoro jedni userzy niejakoby dziedzicza funkcjonalnosc drugich, czemu by nie umiescic tych dodatkowych informacji w tabeli w relacji 1:1? Takie rozwiazanie pomaga podczas operacji na userach rozszerzonych (obsluga trigerami) oraz pozwala na ew rozwijanie funkcjonalnisci, a dodatkowo ulatwia dministracje i zachowuje duza spojnosc danych. Jesli ktos nie wpadnie na genialny pomysl zeby z bazy wyciagac informacje JOINami co znacznie spowalnia i w praktyce jest wykozystywane naprawde oszczednie zapytania beda naprawde blyskawiczne. Jesli natomiast jeszcze za wolno to mozna zawsze memcache'yc wyniki:) Wtedy juz smiga jak ta lala:) Jesli ktos nie wierzy niech odpali sobie pare takich zapytan z EXPLAIN SELECT i zobaczy ile trwaja operacje zwiazane z obsluga tabeli w porownani z wyszukiwanie danych:)

Pozdrawiam