Logowanie użytkowników, a tabele względem rol

Cześć,

zaczynam kodzic sobie cruda wspomagającego zarządzanie szkołą. Coś takiego jak tu, ale wzbogaconego m.in. o logowanie użytkowników.
I przechodząc do sedna: mamy uczniów i nauczycieli. (No i jeszcze jakiś adminów) Chciałbym żeby wszyscy logowali się z poziomu tego samego formularza bez żadnych rozgraniczeń na logowanie dla nauczycieli i uczniów. To system ma rozpoznać rolę danego użytkownika.

Pytanie jak ogarnąć logowanie? Myślałem o jednej tabelce users oraz tabelce roles. Users zawierałaby id hasło i login i jakiś odnośnik do roli. Ale co dalej? Stworzyć tabele students i teachers i połączyć je kluczem obcym po id usera z tabelą users? Czy tak się w rzeczywistości robi? Jakie byłyby wady takiego rozwiązania? A może robi się zupełnie inaczej?

Chory Kret napisał(a):

Myślałem o jednej tabelce users oraz tabelce roles. Users zawierałaby id hasło i login i jakiś odnośnik do roli.

dobry początek

Stworzyć tabele students i teachers i połączyć je kluczem obcym po id usera z tabelą users?

a tu już niekoniecznie, chociaż to powinno wyjść z normalizacji. Jakie pola mają mieć studenci i jakie nauczyciele, ile jest wspólnych (to musisz zrobić to Ci wszystko się wyklaruje) i czy dla dwóch pól opłaca się tworzyć dodatkowe tabele

Wstępnie szacuję, że będzie dużo oddzielnych pól (w przypadku nauczycieli choćby informacje o stanowisku czy etacie). No i będą zupełnie inne relacje do innych tabel (zapisy na poszczególne przedmioty, zaliczenia itp)

nie szacuj wstępnie tylko weź się do roboty, weź kartkę (wirtualną lub rzeczywistą) i wypisz wszystkie pola jakie potrzebujesz. Co to za moda, żeby zamiast siąść i zrobić raz a dobrze kombinować jak koń pod górkę. Nie masz doświadczenia w projektowaniu BD więc zrób to tak jak należy krok po kroku.

Chory Kret napisał(a):

Pytanie jak ogarnąć logowanie? Myślałem o jednej tabelce users oraz tabelce roles. Users zawierałaby id hasło i login i jakiś odnośnik do roli. Ale co dalej?

Role będą mogły być dynamicznie dodawane albo edytowane? Bo jeśli nie, to nie potrzebujesz na nie tabelki, wystarczy kolumna w bazie mapowana na enuma.

Stworzyć tabele students i teachers i połączyć je kluczem obcym po id usera z tabelą users? Czy tak się w rzeczywistości robi? Jakie byłyby wady takiego rozwiązania?

Tak, tak się robi. Jakie widzisz alternatywy?

Masz rację tak zrobię. A pomijając na chwilę wspólne pola - co z relacjami? Uczeń ma relacje do innych tabel niż nauczyciel. Czy w takim przypadku istnieje w ogóle inne rozwiązanie niż tabela users + tabele teachers i students?

Chory Kret napisał(a):

Masz rację tak zrobię. A pomijając na chwilę wspólne pola - co z relacjami? Uczeń ma relacje do innych tabel niż nauczyciel. Czy w takim przypadku istnieje w ogóle inne rozwiązanie niż tabela users + tabele teachers i students?

Edit:
@somekind Role będą ustalone tj. uczeń, nauczyciel i admin. Z tymi rolami to wykorzystam rozwiązanie z asp mvc individual user accounts i tabelka roles będzie mi chyba potrzebna do logowania się (a następnie dawania dostępu do określonych kontrolerów/akcji).
Pomyślałem jeszcze o jednej tabelce users ze wszystkimi możliwymi polami zarówno nauczyciela, ucznia i admina i niektóre z nich byłyby nullami (również klucze do innych tabel). Ale wydaje mi się to jakieś mało przejrzyste.

Nie ma czegoś takiego jak "relacja do tabeli": https://pl.wikipedia.org/wiki/Model_relacyjny#Podej.C5.9Bcie_intuicyjne

O ile dobrze rozumiem problem z uczniami, nauczycielami i uzytkownikami, to Twoim problemem jest reprezentowanie w bazie danych dziedziczenia klas. Są trzy sposoby jego implementacji: Table Per Hierarchy, Table Per Type, Table Per Class. Możesz też nie wiązać tych trzech bytów w hierarchię, ale w celach edukacyjnych chyba lepiej poćwiczyć to dziedziczenie.

Dokładnie taki jest problem. Dzięki za podanie nazw tych implementacji. Zapoznam się z tymi sposobami i przekminię, który będzie najlepszy