[SQL] prawidłowa normalizacja, czyli jak podzielić tablicę użytkowników Opcje

[norgoth]

Właśnie walczę z problemem, podziału tabeli użytkowników na mniejsze. Wszystko dlatego, że w tabeli mają być dwa typy użytkowników, dla przykładu student i wykładowca. Oba typy mają mieć takie same kolumny z informacją o użytkowniku, przy czym dla wykładowców ma być o kilka kolumn więcej z ustawieniami konta (~6 kolumn z danymi typu ENUM 'Y', 'N' opisujące opcje w stylu "wyślij powiadomienie email kiedy nadejdzie nowa wiadomość", przy czym studenci wykorzystują tylko ~2 z nich).

I teraz 4 dopuszczalne rozwiązania:

- 1 tablica "uzytkownicy"
gdzie wszystkie kolumny opcji niedostępnych dla studentów mają wartość NULL (raczej wykluczam że to poprawne)

- 2 tablice "studenci" i "wykładowcy"
gdzie studenci mają tylko ~2 kolumny ustawień, a wykładowcy ~6 (z tego ~2 są identyczne jak te u studentów)

- 2 tablice "uzytkownicy" i "ustawienia"
gdzie tablica ustawienia zawiera klucze obce wg. ID wykladowcow, ale w tablicy uzytkowników też muszą znaleźć się ~2kolumny ustawień które dotyczą wszystkich użytkowników

- 3 tablice "uzytkownicy", "ustawienia_s" (dla studentów), "ustawienia_w" (dla wykladowcow)

Które z tych rozwiązań jest najbardziej poprawne?

Ten post edytował norgoth 3.07.2008, 19:39:53

[mike]

~qrees nie cały świat w okół CMSów się kręci.
Rozdzielenie na dwie tabele jest poprawne jełśi są to dwa odrębne obiekty.

Jeśli są to zaś dwa typy tego samego obiektu to powinna być wprowadzona tabela z ustawieniami. Ale tego nie wiemy.

Jeśli studenci i wykładowcy mają wspólny tylko login i hasło to nie są to te same obiekty i wypadają do dwóch tabel.

[qrees]

~qrees nie cały świat w okół CMSów się kręci.
Rozdzielenie na dwie tabele jest poprawne jełśi są to dwa odrębne obiekty.

Jeśli są to zaś dwa typy tego samego obiektu to powinna być wprowadzona tabela z ustawieniami. Ale tego nie wiemy.

Jeśli studenci i wykładowcy mają wspólny tylko login i hasło to nie są to te same obiekty i wypadają do dwóch tabel.

No niestety nie zgodzę się. Jeżeli mają wspólny login i hasło i obaj mogą korzystać z jakiegoś interfejsu do logowania (prawdopodobnie tego samego), to jest podstawa do tego żeby umieścić ich w jednej tabeli. zarządzanie użytkownikami znacznie się uprości. CMS to był tylko przykład. To że w CMS'ach robi się to w ten sposób, to nie znaczy że to jest jakaś fanaberia twórców CMS'ów, tylko jest za tym jakaś głębsza myśl. Poza tym, nie tylko w CMS'ach się tak robi, ale praktycznie wszędzie. Mamy tabelę z użytkownikami której używamy do zarządzania nimi, a to że ktoś tam w niej jest wykładowcą, ktoś studentem, od tego są rzeczy takie jak grupy, klucze obce itd.