![]() |
![]() ![]() |
![]() |
![]()
Post
#1
|
|
Grupa: Zarejestrowani Postów: 2 Pomógł: 0 Dołączył: 20.06.2010 Ostrzeżenie: (0%) ![]() ![]() |
Witam,
przygotowałem bazę w której umieszczone zostaną dane uczestników pewnej imprezy. Kierowałem się zasada modularnosci, wiec ostatecznie wyszło mniej więcej tak:
Jako ze nie jestem doświadczony w projektowaniu baz, nie jestem przekonany czy taki rozkład ma sens i czy stosuje się coś takiego w praktyce, czy może wystarczy po prostu w jednej tabeli zamieszczać dane indywidualne uczestnika (t.j. imię, nazwisko, cały adres, telefon, zakwaterowanie itd.) a tylko dane które mogą być przypisane również innym uczestnikom czyli np. kraj, miejscowość, hotel dolaczac do tabeli za pomocą id'kow? Wszystko fajnie wyglądało na początku, później troszkę schodów miałem z tworzeniem zapytań, ale udało się, a teraz dodaje opcje edycji tych danych i widzę, ze kupę zamieszania z nimi jest.. Czy któryś z doświadczonych tutaj kolegów mógłby coś zasugerować i może z własnego doświadczenia stwierdzić jaki model danych jest korzystniejszy. Będę wdzięczny za wszelkie uwagi. |
|
|
![]()
Post
#2
|
|
Grupa: Zarejestrowani Postów: 1 135 Pomógł: 158 Dołączył: 19.03.2009 Skąd: Toruń Ostrzeżenie: (0%) ![]() ![]() |
W twoim przypadku zrobił bym jedną tabele czemu a dlatego że posiadasz tylko same dane adresowe dla poszczególnej osoby nie potrzebnie tworzysz oddzielne tabele dla adresu i dla email np. to nie jest sklep czy jakaś duża aplikacja żeby tworzyć dane cząsteczkowe później relację między nimi .
|
|
|
![]()
Post
#3
|
|
Grupa: Zarejestrowani Postów: 855 Pomógł: 145 Dołączył: 17.07.2008 Skąd: High Memory Area Ostrzeżenie: (0%) ![]() ![]() |
Poza tym masz relacje w złym kierunku. To raczej zakwaterowanie powinno odwoływać się do uczestnika a nie odwrotnie.
|
|
|
![]()
Post
#4
|
|
Grupa: Zarejestrowani Postów: 2 Pomógł: 0 Dołączył: 20.06.2010 Ostrzeżenie: (0%) ![]() ![]() |
@krzysztof_kf: no tutaj racja.. to powiazanie za pomoca tabeli dane_kontaktowe niepotrzebnie mi komplikuje pozniej zapytanie.. to wywale i wstawie po prostu adres_id i telefon_email_id - lub moze w ogole w jednej tabeli tak jak piszesz. Jednak jakos sklaniam sie ku rozdzielaniu takich danych (jak adres, telefony), ale wlasciwie nie wiem co moze mi to dac (hmm troche smiesznie to brzmi) oprocz tego, ze tabela bedzie czytelniejsza (mniejsza), bo i tak sa to dane, ktorych z innymi uczestnikami nie powiaze, a jednak intuicja mowi mi, aby je rozdzielac.. ta sklonnosc do rozbijania rzeczy na mniejsze moduly to pewnie z programowania;)
@Mchl: czy masz na mysli takie powiazanie?: tabela zakwaterowanie: uczestnik_id, hotel_id, od_kiedy, do_kiedy wtedy w sumie latwo zapytac o liste osob w danym hotelu.. nie wspomnialem jednak, ze kazda osoba nalezy rowniez do grupy i ta grupa tez powiazana jest ogolnie z hotelem i zaplanowanym pobytem wiec tak jak jest u mnie obecnie to w skrocie wyglada tak:
Chodzi o to, ze tworzac grupe mozna nadac jej hotel domyslny wraz z domyslnymi datami pobytu tak, ze przy dodawaniu uczestnika do grupy przydzielone bedzie mial zakwaterowanie domyslne, ktore bedzie mozna od razu indywidualnie dla niego zmienic. Z tego powodu uczestnik i grupa odwoluja sie do zakwaterowania a nie odwrotnie.. a jezeli mimo to powinno byc odwrotnie to moglbys prosze mi to wyjasnic, jakos uzasadnic? |
|
|
![]() ![]() |
![]() |
Aktualny czas: 30.09.2025 - 08:42 |