Co nam daje takie rozwiązanie ?
W sensie w relacjach :dependent - czyli zależnych. Np. Faktura - Pozycja Faktury albo jak tutaj
w powiązaniu TypRozgrywki - Rozgrywka ?
Daje to mniej potem joinów w SQL czy co ? Czy po prostu to tylko charakter związku w sensie związek jest mocniekszy coś nie może istnieć bez czegoś ?
gdfsfsa napisał(a):
a jak inaczej byś chciał to zrobić?
można zrobić dodatkową kolumnę z ID ale po cholerę skoro relacja jest 1:1? Tylko strata miejsca w bazie
Możesz wyjaśnić bardziej szczegółowo na przykładzie jakimś ?
gdfsfsa napisał(a):
a jak inaczej byś chciał to zrobić?
można zrobić dodatkową kolumnę z ID ale po cholerę skoro relacja jest 1:1? Tylko strata miejsca w bazie
1:1 ????
Tworzenie takiej tabeli (TypRozgrywki) pozwala nam przechowywać dynamiczny typ wyliczeniowy. Zapewnia nam to relację 1:1 (poczytaj o relacjach) i pozwala w dowolnym momencie w prosty sposób dodać nowy element bez modyfikacji struktur tabeli.
Vardamir napisał(a):
Tworzenie takiej tabeli (TypRozgrywki) pozwala nam przechowywać dynamiczny typ wyliczeniowy. Zapewnia nam to relację 1:1 (poczytaj o relacjach) i pozwala w dowolnym momencie w prosty sposób dodać nowy element bez modyfikacji struktur tabeli.
To jest dokładniej mówiąc wiązanie ... Relacja to tabela . krotki (poczytaj dokładnie o modelu relacyjnym).
Ja pokazałem na przykładzie powiązanie 1 - N .
kadoel napisał(a):
To jest dokładniej mówiąc wiązanie ... Relacja to tabela . krotki (poczytaj dokładnie o modelu relacyjnym).
Ja pokazałem na przykładzie powiązanie 1 - N .
Znam model relacyjny (dokładnie). Mój błąd, tam jest 1:N. Ten zabieg pozwala ograniczyć pole wyboru wartości atrybutu przez dynamiczny typ wyliczeniowy jakim jest relacja TypRozgrywki. Skoro mamy pewien zbiór danych, które będą się powtarzać to czasami warto stworzyć dodatkową relację i więz integralności w postaci klucza obcego do niej. Zapewni nam to, że tylko te wartości będą mogły się pojawić (spójność). Dodatkowo w łatwy sposób można dodać nową wartość dla tego atrybutu lub zmodyfikować istniejącą (bezpieczeństwo dla danych w relacji Rozgrywki). Dzięki takiemu rozwiązaniu, przykładowo jesteśmy chronieni przed usunięciem typu rozgrywek, które nadal są prowadzone (istnieją krotki mająze dowiązanie do relacji TypRozgrywki) oraz nie możemy dodać rozgrywek o typie, który nie istnieje.
Vardamir napisał(a):
kadoel napisał(a):
To jest dokładniej mówiąc wiązanie ... Relacja to tabela . krotki (poczytaj dokładnie o modelu relacyjnym).
Ja pokazałem na przykładzie powiązanie 1 - N .Znam model relacyjny (dokładnie). Mój błąd, tam jest 1:N. Ten zabieg pozwala ograniczyć pole wyboru wartości atrybutu przez dynamiczny typ wyliczeniowy jakim jest relacja TypRozgrywki. Skoro mamy pewien zbiór danych, które będą się powtarzać to czasami warto stworzyć dodatkową relację i więz integralności w postaci klucza obcego do niej. Zapewni nam to, że tylko te wartości będą mogły się pojawić (spójność). Dodatkowo w łatwy sposób można dodać nową wartość dla tego atrybutu lub zmodyfikować istniejącą (bezpieczeństwo dla danych w relacji Rozgrywki). Dzięki takiemu rozwiązaniu, przykładowo jesteśmy chronieni przed usunięciem typu rozgrywek, które nadal są prowadzone (istnieją krotki mająze dowiązanie do relacji TypRozgrywki) oraz nie możemy dodać rozgrywek o typie, który nie istnieje.
Ta relacja jest 1-N.
Chyba nie zrozumiałeś do końca tej notacji.
TO czym się różni w takim razie 1-N na tym przykładzie gdzie klucz z tabeli TypRozgrywki przechodzi do Rozgrywki i staje się kluczem obcym, a czym jeśli wchodzi w cześć klucza głównego.
Dobre, aż się uśmiechnąłem ;) Pracuje zawodowo w bazach danych w bardzo dużej firmie i zapewniam Cię, że radzę sobie bardzo dobrze. Miałem na studiach bazy danych - poznałem model relacyjny i uważam, że rozumiem go wystarczająco, ale może to tylko wrażenie moje i prowadzącego. Skoro nie potrafię rozwiązać tego kolokwium, to zważając na to co przed chwilą napisałem, forma tego przedmiotu kompletnie nie przygotowuje do pracy związanej z bazami danych. Nigdy na rozmowie kwalifikacyjnej nie miałem żadnych pytań w tym kierunku. Ceniona jest umiejętność pracy z realnymi danymi (indeksy, transakcje, optymalizacja zapytań, praca na wielu bazach), a nie dywagacje teoretyczne. Ale to wyłącznie moja subiektywna opinia, może ten przedmiot przygotowuje do doktoratu w tym kierunku. Ja już tutaj odpowiadał nie będę, żeby tematu nie zaśmiecać bo robi się z tego offtop niezwiązany z problemem. Powodzenia w nauce i na kolokwium ;)
Vardamir napisał(a):
Dobre, aż się uśmiechnąłem ;) Pracuje zawodowo w bazach danych w bardzo dużej firmie i zapewniam Cię, że radzę sobie bardzo dobrze. Miałem na studiach bazy danych - poznałem model relacyjny i uważam, że rozumiem go wystarczająco, ale może to tylko wrażenie moje i prowadzącego. Skoro nie potrafię rozwiązać tego kolokwium, to zważając na to co przed chwilą napisałem, forma tego przedmiotu kompletnie nie przygotowuje do pracy związanej z bazami danych. Nigdy na rozmowie kwalifikacyjnej nie miałem żadnych pytań w tym kierunku. Ceniona jest umiejętność pracy z realnymi danymi (indeksy, transakcje, optymalizacja zapytań, praca na wielu bazach), a nie dywagacje teoretyczne. Ale to wyłącznie moja subiektywna opinia, może ten przedmiot przygotowuje do doktoratu w tym kierunku. Ja już tutaj odpowiadał nie będę, żeby tematu nie zaśmiecać bo robi się z tego offtop niezwiązany z problemem. Powodzenia w nauce i na kolokwium ;)
Jeśli nie zrozumiałeś mojego prostego pytania. No to widzę jakie masz braki wiedzy w podstawach.
Skoro nie widzisz różnicy czy klucz obcy wchodzi w skład klucza głównego bądź nie to nie mamy o czym rozmawiać ....
MySQL 
PostgreSQL