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ń ?

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.

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

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 ?

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

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.

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.

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

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.

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?

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.

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.

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

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