Witam,
jestem w trakcie tworzenia aplikacji która ma ułatwić zarządzanie klubem sportowym. Zacząłem od porządnego zaprojektowania struktury bazy danych i zastanawia mnie pewna kwestia.. Mianowicie w bazie muszą być przechowywane informacje o osobach, które posiadają różne "statusy" i tym samym różne dane będą przechowywane na ich temat.

Mniej więcej takie "typy" osób powinny być przechowywane w bazie:

Jak widać każda z tych typów różni się od siebie kilkoma kolumnami (imie i nazwisko powtarza się wszędzie). Po którce wyjaśnie o co chodzi...
Użytkownik jest to osoba która jest w klubie i posiada swoje konto. Administrator tez jest uzytkownikiem więc pewnie wystarczy dodać pole boolowskie 'admin' i sprawa będzie załatwiona (może to być jedna wspólna tabela).

Natomiast zawodnik jest innym rodzajem użytkownika, tzn nie posiada konta w bazie na które moze się zalogowac do systemu, ale jest osobą która przyjechała na organizowane zawody, np. lekkoatletyczne i jest ona wprowadzana do systemu aby nadac jej numer identyfikacyjny dzięki któremu bedzie wiadomo w jakich konkurencjach taka osoba brała udzial oraz jakie wyniki osiągnęla, aby na końcu móc przygotować tabele z końcowymi wynikami wszystkich zawodników..

Trzeba tutaj dodać, że każdy użytkownik (posiadający konto w systemie) jest niejako "automatycznie" zawodnikiem, ale nie każdy zawodnik jest uzytkownikiem.. Dodatkowo należy uwzględnich taką sytuację, że zawodnik nie posiadający dotychaczas swojego konta, zechce je założyć i stanie się użytkownikiem..

Może wiecie jak takie informacje zazwyczaj zapisuje się w bazie danych albo jak Wy byście to zrobili ? Czy tworzy się osobne tabele dla uzytkownika i zawodnika ? (ale wtedy powstaje redundancja danych i problem z "transformacją" zawodnika do uzytkownika)

Pozdrawiam i czekam na sugetie..
Michał

możesz spróbowac zrobić coś ala (na szybko wyskrobane):

osoba (id,id_type_osoba,imie,nazwisko,mail)
//id_type_osoba - jest polem pomocniczym, jakbyś potrzebował wylistować osoby i ich typy (admin, zawodnik, sedzia,klubowicz).

uzytkownik (id,id_osoba,email,haslo,typ_uprawnien)
//Użytkownikiem może być w takim przypadku każda "osoba" - ale nie musi. I nadajesz odpowiedni typ uprawnień.

osoba_zawodnik (id_osoba)
osoba_klient(id_osoba,adres)
osoba_sedzia (id_osoba, nr_licencji, stopien)

@Lysiur - dzięki za zainteresowanie.

Czyli o ile dobrze rozumiem, tworzona jest tabela osoba, w której jest id_type_osoba i wtedy w zależności od "typu" danego uzytkownika wypisywane są charakterystyczne dla niej dane?
Czyli użytkownik musi zawierać klucz obcy z tabeli osoba, aby "zaopatrzyć się" w pełne informacje?

Jeżeli tak to ma wyglądać, to chyba można to tak zrobić? Pytanie jest - czy to jest dobra praktyka (i tak to się robi) ?
Bo ogólnie dość dużo złączeń wtedy wychodzi, no ale gdzieś na taki zarzuty czytałem odpowiedzi typu : "bo w końcu to baza relacyjna i muszą byc relacje"

Jeżeli przewidujesz dużo typów oraz to, że ich przybędzie to wtedy robisz tabele.
KTO | NAZWA | WARTOŚĆ
podobnie jak przy atrybutach produktów (każdy ma inne).

Tutaj mniemam, że pula typów się nie zmieni więc to co kolega podał jest prawidłowe.
Wyciągasz wspólny mianownik wszystkich typów kont - ID, Imię, Nick, E-mail i Hasło.
Nawet jak hasło nie u każdego jest to w niczym nie zaszkodzi kolumna z NULL / PUSTA.
Ważne jest aby nie umieszczać w tabeli users atrybutów charakterystycznych dla jednego, dwóch typów np. nr licencji.

@markonix - dzięki za odpowiedz i utwierdzenie w podejściu do sprawy..

Ogólnie nakreśliłem taki schemat:

Nie jest on super kompletny (bo zabrakło sędziego), ale chodziło o koncepcje..

Moje pytania/wątpliwości...
- Na powyższym schemacie rozrysowałem admina i uzytkownika osobo, ale w sumie czy w sumie nie wystarczylo by dodać dodatkową kolumnę, w której sygnalizowałoby się admina ? ( z tym, że adminów będzie z 2-3-ech a uzytkowników kilkudziesięciu..)

- patrzac na ten schemat wydaje mi się, że brakuje jednoznacznego identyfikatora danej osoby.. Wpadłem na pomysł, aby wprowadzić kolumnę PESEL (do tabeli Person), która zapewni unikalność danej osoby.. z tym, że myślałem również o zastosowaniu peselu jako loginu danego uzytkownika...

Co radzicie?

Myślę, że możesz z tabeli Administrator i Użytkownik, zrobić jedną tabelę:

accounts: id | idosoba| id_role | login | haslo |

i aby rozróżnić uprawienia user/admin, wykorzystać albo flagę (lub jeśli masz więcej rodzajów uzytkowników) zrobić tabelę roles w której miałbyś zbiór dostępnych ról.

roles: id | name | ....

Dodatkowo w tabelach odwzorujących typy osób, usunął bym kolumne id, i idosoba zrobił jako klucz główny do dalszych połączeń. ale to zależy co chcesz osiągnąć.

Bo np.: teraz 1 osba może zosać kilka razy klubowiczem (mieć kilka dat wstąpienie i wystąpienia), to samo z klientem.

OK, dzięki za rady... Z tymi kluczami w tabelach odwzorujących typy osób to może dobry pomysł, bo daje to w sumie jaieś zabezpieczenie przed ewentualną replikacją..
Natomiast odnośnie tych ról.. to też w sumie niezły pomysł z tym, że nie wiem czy jest to potrzebne.. bo chyba będzie właśnie tylko admin i zwykły użytkownik, no i tych adminów będzie z dwóch, więc czy jest sens NULL'ować praktycznie całą kolumne? Teoretycznie można tak zrobić, ale to nie będzie miało jakiegoś negatywnego wpływu np. na wydajność?

Naprościej zrobić kolumnę 0 / 1 is_admin domyślnie koniecznie zero.

Ok, naniosłem w sumie te drobne zmiany na diagram i wrzucam go do wglądu.. Ogólnie to po wskazówce @Lysiur'a odnosnie tych unikalnych kluczy wpadłem na pomysł, aby może ten klucz unikalny stanowił PESEL ? (akutalnie na diagramie jest to jako dodatkowe pole, bo ta idea pojawiła się właśnie w trakcie pisania tego posta | Można/warto tak zrobić? )



---
Przy okazji chciałbym poruszyć kwestie tworzenia/wstawiania poszczególnych typów osób.. Chcąć np. utworzyć użytkownika lepiej wykorzystać trigger czy procedure ? (a może jeszcze coś innego?) Ja bym to widział tak: w procedurze wstawiam najpierw do tabeli Person, a następnie do tabeli Uzytkownik z wykorzystaniem utworzonego id jako referencji..(lub wspomnianego PESELU)

Jak to się poprawnie powinno odbywać?