Witajcie!
Właśnie jestem w trakcie (któryś raz z kolei) nauki PHP i MySQL. Przyłożyłem się i chyba wiem do czego są relacje.
Krótko mówiąc służą one temu, aby nie dało się usunąć pewnych rekordów, jeżeli doprowadzi nam to do sytuacji takiej, że w innych tabelach zostaną rekordy które staną się nieprzydatne.
Jeżeli to jest jedyna funkcja relacji to o co takie wielkie halo?
A może wyciągnąłem pochopne wnioski i się mylę?
Pełna wersja: [MySQL] Co nam dają relacje?
No cóż relacje pozwalają na zmniejszenie objętości baz danych (przy tym prostym przykładzie już da się zauważyć spory zysk) bo zamiast:
tabela user (imię, nazwisko, zawod)
janek, jakis, stolarz
marek, jakis, stolarz
janko, muzykant, górnik
itp.
można zrobić 2 tabele
user (imię, nazwisko, id_zawodu)
janek, jakis, 1
marek, jakis, 2
janko, muzykant, 2
zawod(nazwa)
-stolarz
-górnik
-hutnik
Dodatkowo znacznie szybciej można modyfikować dane, bo załóżmy, że wszyscy stolarze są teraz nazywani specjalista od drewna wystarczy wtedy zmodyfikować pole w tabeli zawód, zamiast każde pojedyncze pole z tabeli user gdzie mamy stolarza w zawodzie
Łatwiej się również projektuje takie bazy.
tabela user (imię, nazwisko, zawod)
janek, jakis, stolarz
marek, jakis, stolarz
janko, muzykant, górnik
itp.
można zrobić 2 tabele
user (imię, nazwisko, id_zawodu)
janek, jakis, 1
marek, jakis, 2
janko, muzykant, 2
zawod(nazwa)
-stolarz
-górnik
-hutnik
Dodatkowo znacznie szybciej można modyfikować dane, bo załóżmy, że wszyscy stolarze są teraz nazywani specjalista od drewna wystarczy wtedy zmodyfikować pole w tabeli zawód, zamiast każde pojedyncze pole z tabeli user gdzie mamy stolarza w zawodzie
Łatwiej się również projektuje takie bazy.
Cytat
A może wyciągnąłem pochopne wnioski i się mylę?
Tak. Myslisz się.
Głównym zadaniem relacji jest powiązanie ze sobą danych z różnych tabel, poprzez tzw. klucze (unikalne w skali bazy). To, o czym piszsz, to "efekt uboczny".
@lobopol
No ja znam tę funkcjonalność o której piszesz
Najprostszym jej przykładem jest zastosowanie tabeli słownikowej z województwami.
Mamy na przykład tabelę użytkownicy a w niej kolumnę z nazwaUżytkownika i województwoUżytkownika w którym trzymamy cyferki (idWojewództwa) a drugiej tabeli województwa mamy idWojewództwa z cyferkami i nazwaWojewództwa.
I teraz jak chcemy zrobić tak, aby pobrać dane do tablicy z tabeli użytkownicy z obu kolumn, ale żeby w drugiej nie mieć cyferek tylko nazwy to po prostu zadajemy odpowiednie zapytanie.
To są te magiczne relacje? Bo mi się wydawało, że do relacji trzeba jakieś klucze obce stosować.
Kurczę może wypisuje jakieś bzdury bo to pojęcie jest dla mnie strasznie abstrakcyjne.
Swoje wnioski wyciągnąłem stąd:
http://forum.di.com.pl/showthread.php?t=7672
i stąd: http://209.85.129.132/search?q=cache:http:...zy/relacje.html
No ja znam tę funkcjonalność o której piszesz
Najprostszym jej przykładem jest zastosowanie tabeli słownikowej z województwami.
Mamy na przykład tabelę użytkownicy a w niej kolumnę z nazwaUżytkownika i województwoUżytkownika w którym trzymamy cyferki (idWojewództwa) a drugiej tabeli województwa mamy idWojewództwa z cyferkami i nazwaWojewództwa.
I teraz jak chcemy zrobić tak, aby pobrać dane do tablicy z tabeli użytkownicy z obu kolumn, ale żeby w drugiej nie mieć cyferek tylko nazwy to po prostu zadajemy odpowiednie zapytanie.
To są te magiczne relacje? Bo mi się wydawało, że do relacji trzeba jakieś klucze obce stosować.
Kurczę może wypisuje jakieś bzdury bo to pojęcie jest dla mnie strasznie abstrakcyjne.
Swoje wnioski wyciągnąłem stąd:
http://forum.di.com.pl/showthread.php?t=7672
Cytat
we wszystkich bazach SQLowych (nawet w Oraclu) relacje tworzy się w zapytaniach, w bazie sie ich nie zapisuje, bo nie ma to zbytniego sensu. Oczywiście, narzędzia, które wspomagają tworzenie zapytań, np. jak edytor kwerend w MS Access pokazują graficznie relacje, ale...
Relacje dodaje się w zapytaniach po klauzuli WHERE np.
SELECT * FROM imie,nazwisko WHERE imie.id_imie = nazwisko.id_imie;
lub
SELECT * FROM imie,nazwisko WHERE imie.id_nazwisko = nazwisko.id_nazwisko;
lub, jeśli baza danych jest niespójna ( relacja 1:1 nie jest zachowana)
SELECT * FROM imie,nazwisko WHERE imie.id_imie = nazwisko.id_imie AND imie.id_nazwisko = nazwisko.id_nazwisko;
w twoim przypadku, to automatyczne przypisanie kluczy musisz albo zaimplementować w programie, który odwołuje sie do bazy, aby robił takie rzeczy (jak zauważyłeś, mało elegancka metoda, ale powszechnie stosowana ) , albo musisz napisać trigger - to taki "program", który wywoła się w konkretnych wypadkach ( w twoim przypadku bedzie to aktualizacja tabeli imie badz nazwisko) i wykona odpowiednia operacje ( w tym wypadku aktualizacja kluczy.
Triggery są w MySQLu od niedawna, sam jeszcze nie wiem, jak się je tworzy w tej bazie, więc musisz popytać wujka googla
Mam nadzieje, że to wystarczająco konkretna odpowiedź
Relacje dodaje się w zapytaniach po klauzuli WHERE np.
SELECT * FROM imie,nazwisko WHERE imie.id_imie = nazwisko.id_imie;
lub
SELECT * FROM imie,nazwisko WHERE imie.id_nazwisko = nazwisko.id_nazwisko;
lub, jeśli baza danych jest niespójna ( relacja 1:1 nie jest zachowana)
SELECT * FROM imie,nazwisko WHERE imie.id_imie = nazwisko.id_imie AND imie.id_nazwisko = nazwisko.id_nazwisko;
w twoim przypadku, to automatyczne przypisanie kluczy musisz albo zaimplementować w programie, który odwołuje sie do bazy, aby robił takie rzeczy (jak zauważyłeś, mało elegancka metoda, ale powszechnie stosowana ) , albo musisz napisać trigger - to taki "program", który wywoła się w konkretnych wypadkach ( w twoim przypadku bedzie to aktualizacja tabeli imie badz nazwisko) i wykona odpowiednia operacje ( w tym wypadku aktualizacja kluczy.
Triggery są w MySQLu od niedawna, sam jeszcze nie wiem, jak się je tworzy w tej bazie, więc musisz popytać wujka googla
Mam nadzieje, że to wystarczająco konkretna odpowiedź
i stąd: http://209.85.129.132/search?q=cache:http:...zy/relacje.html
Cytat
Co to wszystko nam daje?
Jeśli w tabeli zamowienia mamy w polu id_klienta wartość, która nie odpowiada żadnej z wartości klucza głównego w tabeli klient to mamy problem. Oznacza to bowiem, że mamy zamówienie i nie wiemy kto je złożył. Co prawda, możemy w aplikacji, która z takiej bazy danych korzysta, wprowadzić odpowiednie sprawdzenie i reakcję na tego typu błędy, to jednak dużo bezpieczniej i wygodniej jest dbać o integralność danych w samej bazie danych. A zatem definiowanie relacji pomiędzy danymi w różnych tabelach umożliwia nam zachowanie logicznej integralności danych, w taki sposób aby można było bezpiecznie i logicznie (a jednocześnie nie powtarzając danych) wprowadzać i przechowywać dane i korzystać z nich.
Jeśli w tabeli zamowienia mamy w polu id_klienta wartość, która nie odpowiada żadnej z wartości klucza głównego w tabeli klient to mamy problem. Oznacza to bowiem, że mamy zamówienie i nie wiemy kto je złożył. Co prawda, możemy w aplikacji, która z takiej bazy danych korzysta, wprowadzić odpowiednie sprawdzenie i reakcję na tego typu błędy, to jednak dużo bezpieczniej i wygodniej jest dbać o integralność danych w samej bazie danych. A zatem definiowanie relacji pomiędzy danymi w różnych tabelach umożliwia nam zachowanie logicznej integralności danych, w taki sposób aby można było bezpiecznie i logicznie (a jednocześnie nie powtarzając danych) wprowadzać i przechowywać dane i korzystać z nich.
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.