Struktura bazy danych JAKA?

Witam,
przygotowalem baze w ktorej umieszczone zostana dane uczestnikow pewnej imprezy. Kierowalem sie zasada modularnosci, wiec ostatecznie wyszlo mniej wiecej tak:

tabela uczestnika:
id, imie, nazwisko, funkcja, wiek, dane_kontaktowe_id, zakwaterowanie_id

tabela dane_kontaktowe:
id, adres_id, telefon_email_id

tabela zakwaterowanie:
id, hotel_id, od_kiedy, do_kiedy

tabela adres:
ulica, numer_budynku, numer_mieszkania, kod_pocztowy, miejscowosc, kraj_id

itd. i jeszcze drugie tyle..

Jako ze nie jestem tak doswiadczony w projektowaniu baz, nie jestem przekonany czy taki rozklad ma sens i czy stosuje sie cos takiego w praktyce, czy moze wystarczy po prostu w jednej tabeli zamieszczac
dane indywidualne uczestnika (t.j. imie, nazwisko, caly adres, telefon, zakwaterowanie itd.) a tylko dane ktore moga byc przypisane rowniez innym uczestnikom czyli np. kraj, miejscowosc, hotel dolaczac do tabeli za pomoca id'kow?
Wszystko fajnie wygladalo na poczatku, pozniej troszke schodow mialem z tworzeniem zapytan, ale udalo sie, a teraz dodaje opcje edycji tych danych i widze, ze kupe zamieszania z nimi jest.. Czy ktorys z doswiadczonych tutaj kolegow moglby cos zasugerowac i moze z wlasnego doswiadczenia stwierdzic jaki model danych jest korzystniejszy. Bede wdzieczny za wszelkie uwagi.

Masz tam relacje 1:1, którą stosuje się kiedy jest taka potrzeba. W twoim przypadku takiej potrzeby nie ma. Poza tym czy korzystasz z tych członów adresu osobno? Czy tylko jako całego adresu? Jeśli jako całego, to wystarczy zrobić z tego jedno pole (nie ma problemu z postacią normalną bo dane mają być atomowe ze względu na ich użycie).

tabela uczestnika:
id, imie, nazwisko, wiek, funkcja

tabela adresow zamieszkania:
id, uzytkownik_id, ulica, nr domu, nr mieszkania, id_miasta, kod pocztowy

tabela adresow email
id, uzytkownik_id, email

tabela miast:
id, nazwa miasta, id_wojewodztwa

tabela wojewodztw:
id, nazwa wojewodztwa

@cepa: no Twoja koncepcja mnie zastanowiła... szkoda, ze nie dopisałeś jakiegoś komentarza, ale dzięki za strukturę. Kurcze w sumie bardzo przejrzyście dane są rozłożone i chyba coś takiego wykorzystam, tylko, że np. id'ki od adresu nie są mi potrzebne i nie wiem czy tworzenie kolumny dla nich ma sens.. jeżeli ma proszę o jakieś wyjaśnienie, poza tym takie rozłożenie danych jakie zaproponowałeś satysfakcjonuje moja skłonność do rozbijania dużych tabel na mniejsze;) dziękuję

teoretycznie nie są potrzebne, w praktyce jak np usuniesz adres bez id? będziesz porownywał po wszystkich polach?
To jest taka dobra praktyka, żeby do każdej tabeli dodawac unikalne id-miejsca nie zajmuje wiele, a ułatwia pracę

hmm adres bez id nie moze miec miejsca, bo wrzucam go zawsze z idkiem uczestnika, wiec nie wydaje mi sie to problemem. Jak bede usuwal uczestnika to i usune adres z idkiem uczestnika. Wlasnie przygotowalem baze cos na zasadzie tej powyzej z tym wyjatkiem, ze nie umiescilem tych 'dodatkowych' idkow. Niech tylko przytrafi mi sie sytuacja, ze bede ich potrzebowal.. ale jakos naprawde nie jestem w stanie sobie takiej wyobrazic.

A co do tej dobrej praktyki, wlasnie o to mi chodzi, zeby sie w koncu dowiedziec jakie one sa przy tworzeniu struktury bazy. Ok, wiec to jedna z nich. Dobrze wiedziec:) Bede o niej pamietal i jak rzeczywiscie znajde zastosowanie dla tego idka chocby w jednym przypadku to tak zrobie wtedy calosc, ale to przy nastepnej bazie jak mi sie trafi..

Pozwolę sobie dopisać kilka uwag, bo nie jestem do końca pewien, czy to, co proponuje kol. Cepa na pewno jest dobrym pomysłem. Przede wszystkim nie upierałbym się tak za dodawaniem dodatkowego id gdzie tylko popadnie...

cepa napisał(a)

tabela uczestnika:
id, imie, nazwisko, wiek, funkcja

tabela adresow zamieszkania:
id, uzytkownik_id, ulica, nr domu, nr mieszkania, id_miasta, kod pocztowy

Rozbicie tego na 2 tabele ma sens tylko wówczas, gdy dopuszczamy możliwość, że uczestnik może nie mieć adresu wcale, lub mieć więcej, niż 1 adres. W przeciwnym wypadku ja tu widzę tylko niepotrzebną komplikację. Wyrzuciłbym id_miasta, kod pocztowy wystarczy jako klucz.

tabela adresow email
id, uzytkownik_id, email

jw.

tabela miast:
id, nazwa miasta, id_wojewodztwa

W miejsce id wstawiłbym kod_pocztowy - będziemy mieli jednoznaczny klucz tabeli, który zarazem niesie ze sobą jakąś sensowną informację, a ponadto załatwimy sobie dodatkową funkcjonalność - automatyczne przyporządkowanie miasta i województwa po podaniu samego tylko kodu pocztowego. W miejsce id_wojewodztwa możemy spokojnie wstawić nazwę województwa...

tabela wojewodztw:
id, nazwa wojewodztwa

...a z tego zrobić tabelę słownikową, z jedną tylko kolumną będącą zarazem kluczem. Z jednej strony uniemożliwi użytkownikom wpisanie dziwnych województw (w przeciwnym wypadku szybko w bazie pojawiłyby się województwa malopolskie, Małopolskie, maoplskie i m-skie, co utrudniłoby potem wyszukiwanie i filtrowanie), a z drugiej strony wyciągając dane z tabeli miasta od razu zobaczymy sensowne dane, bez konieczności dołączania kolejnej tabeli.

@yakhub napisał

Rozbicie tego na 2 tabele ma sens tylko wówczas, gdy dopuszczamy możliwość, że uczestnik może nie mieć adresu wcale, lub mieć więcej, niż 1 adres
Me sens również wtedy gdy kilku uczestników ma ten sam adres, a to jest bardzo realne.

yakhub napisał(a)

...Przede wszystkim nie upierałbym się tak za dodawaniem dodatkowego id gdzie tylko popadnie...

tabela miast:
id, nazwa miasta, id_wojewodztwa

W miejsce id wstawiłbym kod_pocztowy - będziemy mieli jednoznaczny klucz tabeli, który zarazem niesie ze sobą jakąś sensowną informację..

pieknie, miałem dać przykład kodów, ale nie chciało mi się, ale kolega mnie zmusza
dlatego właśnie jestem za dodawaniem id gdzie popadnie.
Otóż kod pocztowy nie jest jednoznaczny!
Przykład:
http://www.poczta-polska.pl/kody/index.php wpisz sobie np 06-211. Ok 10 miejscowości.
A teraz sobie wyobraź, że masz 2 klientów, z dwóch miejscowości o tym samym kodzie pocztowym, a każdy upiera się, żeby na jego fakturze była właściwa nazwa miejscowości.
A teraz wyobraź sobie, że:
-nazwa miejscowości się zmienia, (a faktury trzeba trzymać w oryginalnej formie przez x lat)
-poczta polska zmienia przynależność miejscowości. (j.w)

Sam to przeżyłem, miesiąc roboty, bo ktoś ustawił kod pocztowy jako klucz w tabeli.
Dlatego jestem za dodawaniem unikalnych, pozbawionych znaczenia id w każdej tabeli, zamiast przypisywania id jakiegoś znaczenia.
Pesel podobno również może się powtarzać. A dodanie pola id niewiele kosztuje, wprowadza pewien automatyzm i spójność w bazie, pozwala uniknąć zastanawiania się co też może a co nie może być id i wynikających z tego pomyłek.

Nazwa województwa zamiast id spowoduje większy rozmiar fizyczny bazy danych (ale to pomijalne) i spowolni wykonywanie zapytań-szybciej się porównuje liczby niż teksty. Do tego pozwoli uniknąć np literówek, i zapewni, że województw będzie w bazie 16-doda walidację na poziomie bazy danych, tak, żeby użytkownik nie mógł sobie wpisać nieprawidłowego województwa.

void-tec napisał(a)

Nazwa województwa zamiast id spowoduje większy rozmiar fizyczny bazy danych (ale to pomijalne) i spowolni wykonywanie zapytań-szybciej się porównuje liczby niż teksty. Do tego pozwoli uniknąć np literówek, i zapewni, że województw będzie w bazie 16-doda walidację na poziomie bazy danych, tak, żeby użytkownik nie mógł sobie wpisać nieprawidłowego województwa.

W ogóle wszystkie jednostki administracyjne (od województw do miejscowości) często wygodniej trzymać w jednej tabeli z id, nazwą i id rodzica.