[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]

Z perspektywy teorii poprawną wersją jest wersja z dwoma tabelami. Studenci to całkowicie co innego niż wykładowcy.
Oczywiście zawsze wchodzi w grę możliwość denormalizacji ale to jeśli masz solidne uzasadnienie że studenci i wykładowcy powinni być w jednej tabeli.

Takim uzasadnieniem byłby fakt, że masz zmaiar wykonywać operacji na zbiorze złożonym ze studentów i wykładowców razem.

[qrees]

Z perspektywy teorii poprawną wersją jest wersja z dwoma tabelami. Studenci to całkowicie co innego niż wykładowcy.
Oczywiście zawsze wchodzi w grę możliwość denormalizacji ale to jeśli masz solidne uzasadnienie że studenci i wykładowcy powinni być w jednej tabeli.

Takim uzasadnieniem byłby fakt, że masz zmaiar wykonywać operacji na zbiorze złożonym ze studentów i wykładowców razem.

To pokaż mi CMS'a w którym dwa typy użytkowników są trzymane w dwóch różnych tabelach. Z perspektywy widzenia teorii to powinna być jedna tabela dla użytkowników i dla wykładowców. Ustawienia można trzymać w tej samej tabeli, aczkolwiek może lepiej zastanowić się nad rozwiązaniem: użytkownicy i ustawienia. Pozwoli to na większą elastyczność gdy będzie trzeba dodać jakieś nowe opcje, a nie będzie też zabawy w robienie różnych selektów dla wykładowców i dla użytkowników gdy np trzeba wyświetlić nazwę użytkownika, albo kogoś zalogować.

Dzielenie studentów i wykładowców na dwie tabele jest według mnie złym rozwiązaniem. A co jak pojawię się więcej typów użytkowników? kolejna tabelka? i dla każdego typu użytkownika oddzielny interfejs dostępu do danych?

Ten post edytował qrees 3.07.2008, 19:59:39