[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

[phpion]

Właśnie dopisałeś rozwiązanie z 3 tabelami ja bym właśnie takie wybrał. W tabeli uzytkownicy dodajesz tylko kolumnę np. "typ" określającą czy to student (np. 1) czy wykładowca (np. 2) i na tej podstawie dołączasz odpowiednią tabelę poprzez złączenie.

[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

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

[phpion]

Nie można tego porównać do dziedziczenia z programowania obiektowego? Mamy klasę (tabelę) wyjściową (powiedzmy wręcz abstrakcyjną) uzytkownik, który ma jakieś tam atrybuty. Następnie mamy klasę uzytkownik_student, która rozszerza klasę uzytkownik np. o atrybut nr_indexu. Do tego mamy kolejną specjalizację klasy uzytkownik w postaci uzytkownik_wykladowca, która ma dodatkowy atrybut np. tytul_naukowy. Moim zdaniem właśnie tu sprawdzą się 3 tabele gdyż wykładowca raczej nie ma np. numeru indexu

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

[norgoth]

Dodatkowym problemem jest tutaj kolejna tabela, która właściwie ma być sercem całego systemu. Łączą się w niej w grupy pojedyńczy student i pojedyńczy wykładowca (przy użyciu ich id_studenta i id_wykladowcy), jest tam jeszcze kilka mniej ważnych kolumn, jak nazwa projektu, ocena...

Przy podziale na -studenci -wykladowcy, wyszukując projektu robię odpowiednie joiny i jest wszystko cacy.

Jeśli jednak mam tylko użytkowników to potrzebne są 2 joiny do tej samej tablicy, oba z innymi aliasami (inaczej chyba nie da się skonstruować zapytania).
Ponadto gdyby wkradł się jakiś błąd danych (błędne ID), to w miejscu gdzie powinien sie pojawić wykładowca mółby się pojawić student i odwrotnie.

--- EDIT ---

W sumie ten ostatni to może żaden argument, bo w drugą stronę myśląc pojawiłby się tam błędny wykładowca i tylko taki z tego plus, że wykładowca a nie student

A co z administratorami (np. dziekanat), jeśli ich rola ogranicza się tylko do trzymania porządku i nie biorą udziału w "życiu" systemu?

Ograniczyć się tylko do jednego konta administratorskiego dla wszystkich, czy utwożyć ich wiele?

Czy bezpieczne będzie trzymanie loginów/haseł/danych? administratorów w tej samej tabeli co uzytkownicy czy może inna tabela? A może w ogóle w jakimś pliku na serwerze?

Ten post edytował norgoth 3.07.2008, 21:03:21

[qrees]

No i właśnie... kolejna tabelka dla administratorów, którzy pewnie i tak mają też login, hasło, może jeszcze email, imię itp. Ja trzymam się swojego zdania, że najlepiej jedna tabelka pod tytułem "użytkownicy" i do tego tabelki ustawienia itp. w zależności od potrzeb. Oczywiście to rozwiązanie ma też swoje wady, nie przeczę, ale sądzę że jest bardziej elastyczne i może później zaprocentować.

Co do administratorów to zdecydowanie NIE jedno konto dla wszystkich. Jedno konto łatwiej przejąć, trudniej się zorientować kto co zrobił (czyt. popsuł). Przy jednym koncie pojawią się dodatkowe problemy jak kilka osób będzie chciało się zalogować itp. itd.

Co do trzymania loginów i haseł. Loginy przeważnie trzyma się tak po prostu, natomiast hasła powinno się szyfrować. W razie gdy ktoś włamie się do bazy to i tak mu lista zaszyfrowanych haseł niewiele da. Co do danych.... jak zamierzasz je trzymać, że pytasz czy to jest bezpieczne?

[phpion]

Ja będę nadal się trzymał swojego zdania. Ogólnie powinno się unikać używania kolumn z wartościami NULL, a jeśli wciepiesz wszystko do jednej tabeli to NULLi będzie od groma i trochę. Poza tym dodanie kolejnego typu ludka to kolejna tabela specjalizująca. Wiem, w Twoim przypadku to dodanie nowej kolumny. Ale po co mieszać w istniejącej tabeli? Po co dokładać kolejną (zbędną dla pozostałych przypadków) kolumnę?

[norgoth]

Chyba najbardziej podoba mi się rozwązanie jakie proponuje phpion.

Administratorów i tak będę chyba trzymać w osobnej tabeli. Ich logowanie będzie się odbywać na osobnej, nieoficjalnej podstronie i autoryzacja będzie raczej przebiegać w inny sposób. W ich tabeli, z danych administratorów potrzebne właściwie będą tylko loginy i hasła (@qrees: rzecz jasna że szyfrowane ), ponad to jakieś zakresy ip z jakich dany admin może się zalogować przy założeniu, że większość z nich będzie mogła zrobić to jedynie z komputera w dziekanacie (lub komputerów na terenie szkoły).