Jak działa klucz obcy?

0

Witam,
mógłby mi ktoś wyjaśnić na czym polegają relacje między tabelami w DB?

Chciałbym stworzyć dwie tabele w SQL'u w PHPMyAdmin.
#1:

CREATE TABLE  users (
   id int(11) NOT NULL AUTO_INCREMENT PRIMARY KEY,
   username varchar(100) NOT NULL,
   email varchar(100) NOT NULL,
   pwd varchar(100) NOT NULL
);

(dane z tej tabeli wypełniane są na stronie podczas rejestracji i przesyłane do DB - to akurat mam)

#2:

CREATE TABLE Stats (
   id int,
   strength int(11) DEFAULT 10,
   dexterity int(11) DEFAULT 10,
   FOREIGN KEY (id) REFERENCES users(id)
);

(chciałbym żeby tabela "Stats" była powiązana z tabelą "users" i żeby podczas tworzenia każdego nowego konta dodawała kolejne recordy odpowiadające id z tabeli users)
Przykładowo:

Tabela users

id - 1
username - test
email - [email protected]
pwd - d827d5b5f5131aa84dc29e0dc47da1e9

Tabela Stats
id - 1
strength - 10
dexterity - 10

Wiem, że pewnie zabieram się do tego od "d**y strony" i zapewne gdzieś popełniam błędy, czy mógłby mi ktoś wyjaśnić w jaki sposób na to patrzeć?
Próbowałem już na różne sposoby i za każdym razem powstaje mi pusta tabela.
Jeżeli jest to niewykonalne w ten sposób, to w jaki inny sposób mogę coś takiego zrobić?

Z góry dziękuję za pomoc.

Ps. Proszę o wyrozumiałość, staram się to zrozumieć, uczę się sam, jest to dla mnie zabawa, a nie praca. Nie ma potrzeby, żeby ktoś niepotrzebnie irytował się przez moje głupie, lub wręcz absurdalne pytanie.

Znalazłem na Waszym forum https://www.sqlpedia.pl/kurs-sql/ poczytam i zobaczę czy znajdę tam odpowiedź.

3

Zacząłeś bardzo dobrze.
FOREIGN KEY to głównie informacja o powiązaniu pomiędzy tabelami. Sprawdza też czy dane pasują do siebie (typy/wartości). Możesz tu dodać możliwe zachowania przy usuwaniu lub edycji danych z tabeli nadrzędnej.
https://dev.mysql.com/doc/ref[...]reate-table-foreign-keys.html
Dane w tabeli podrzędnej musisz robić sam (w programie zewnętrznym) lub użyć TRIGGER https://dev.mysql.com/doc/refman/8.0/en/triggers.html

2

Dzięki za informacje, teraz wiem czego szukać.

0
KompletnieZielony napisał(a):

mógłby mi ktoś wyjaśnić na czym polegają relacje między tabelami w DB?

Na niczym, bo coś takiego jak "relacje między tabelami" nie istnieją: http://osilek.mimuw.edu.pl/in[...]-2st-1.2-w02.tresc-1.1-Slajd4
Ogólnie polecam cały ten wykład.

2

@somekind:

somekind napisał(a):
KompletnieZielony napisał(a):

mógłby mi ktoś wyjaśnić na czym polegają relacje między tabelami w DB?

Na niczym, bo coś takiego jak "relacje między tabelami" nie istnieją: http://osilek.mimuw.edu.pl/in[...]-2st-1.2-w02.tresc-1.1-Slajd4

Znalazł się purysta...
I w robocie nigdy nie używasz wiersz a zawsze krotka?
Pewnie rozumieją to tylko Ci co mają lat 50+ :P

Ogólnie polecam cały ten wykład.

Zależy dla kogo.
Jeśli ten wykład zobaczy początkujący, to będzie miał niezły mętlik w głowie.

Dlaczego?
Ponieważ to jest może i niezły wstęp do modelu relacyjnego w ujęciu matematycznym.
Tylko to ma się nijak do nomenklatury używanej nawet przez poszczególne silniki baz danych.

Przykład; pisze się tam o domenie jak o typie danych kolumny (atrybutu), tylko że domena w bazach relacyjnych to jest prawie to samo, ale niezupełnie, ponieważ domena (utworzona przez create domain) definiuje synonim typu danych, który potem można użyć przy definicji atrybutu (pola w tabeli).

Dalej jest ciekawiej; np. pisze, że kolejność wierszy w relacji nie ma znaczenia.
I to prawda dla modelu relacyjnego.
I nieprawda dla relacyjnej bazy danych, gdzie dla danej relacji (tabeli) zdefiniowano klastrowany klucz główny (clustered primary key), który automatycznie wymusza kolejność fizycznego zapisu wierszy wg wartości klucza.
Ale nie zawsze wymusi odczyt danych z tej tabeli wg porządku indeksu klastrowanego - to trochę zawiłe i mocno zależy od danego silnika bazy danych. Chodzi o kolejność wierszy, które zostaną zwrócone z tabeli bez jawnego pokreślenia porządku przez order by. W takim przypadku np. w MSSQL dane zostaną zwrócone wg kolejności najmniejszego indeksu dla danej tabeli - ponieważ optymalizator wybierze najmniejszy indeks do skanu tabeli, a nie zawsze musi to być clustered primary key.

Podobnie jest z zasadą, ze relacja (tabela) nie może zawierać identycznych wierszy (krotek).
No nie może, chyba że dana tabela nie posiada klucza głównego (co jest z definicji fatalną praktyką, ale da się) - wtedy to założenie nie jest prawdziwe.

I tak jest praktycznie w każdej bazie relacyjnej.

Także wykład OK, ale... to jest tylko wierzchołek góry lodowej ;-)

1

@wloochacz: Z tym clustered index w SQLServer to jest tak, że tylko lista w oparciu o którą zbudowany jest indeks jest posortowana. I to tylko logicznie. Fizycznie dane w tabeli leżą losowo. Czyli dane umieszczane są w pliku z danymi tam gdzie instancja znalazła dla nich miejsce.
Podobnie liście indeksu. Każdorazowe wstawienie/usunięcie rekordu lub modyfikacja kolumny na której zbudowany jest indeks klastrowy powoduje jedynie zmianę wskaźników w liście, a nie fizyczną migrację bloków na dysku czy danych w bloku.
Efektem tego jest, że indeks klastrowy działa coraz 'wolniej' na skutek zmian w tabeli i coraz bardziej skomplikowanej struktury wskaźników.

Dyskusje wśród DBA czy, okresowo, przebudowywać indeksy klastrowe czy nie bywają zażarte ;-)

Czytając tabelę z użyciem indeksu klastrowego dostajemy dane posortowane wg kolumn na których został zbudowany, ale czytając dane bez użycia indeksu dostajemy przypadkową kolejność. Na kolejność wierszy w wyniku ma, również wpływ optymalizacja odczytu. Odczyt wg indeksu to czytanie pojedynczych bloków. Pełny skan tabeli pozwala na odczyt wielu bloków jednocześnie.

Ciekawe podsumowanie klastrowych indeksów: https://www.sqlshack.com/desi[...]sql-server-clustered-indexes/

0
wloochacz napisał(a):

Znalazł się purysta...
I w robocie nigdy nie używasz wiersz a zawsze krotka?

Wiersz jest poprawnym określeniem wiersza w tabeli, a relacja nie jest poprawnym określeniem na klucz obcy/związek encji, czy cokolwiek innego, co w ten sposób określacie.
Niechęć do zrozumienia czym jest relacja w kontekście relacyjnych baz danych jest moim zdaniem bardzo dziwnym podejściem. To trochę tak, jakby nie chcieć rozumieć czym jest elektryczność dla silnika elektrycznego.

Wiem, że w dzisiejszych czasach wychwala się ignorancję pod niebiosa i dąży ku niej, no ja jednak wciąż nie będę podążał za tym nurtem. Część ludzi wbrew światu chce poszerzać swoją wiedzę, więc ja będę im pomagał. Nawet jeśli 99% to oleje, to i tak warto.

Jeśli ten wykład zobaczy początkujący, to będzie miał niezły mętlik w głowie.

Dlaczego?
Ponieważ to jest może i niezły wstęp do modelu relacyjnego w ujęciu matematycznym.

To jest kurs dla studentów, czyli właśnie z założenia osób początkujących. Myślę, że nie będzie miał mętliku, jeśli zapozna się z nim w całości, zarówno z wykładem jak i ćwiczeniami.
A może i będzie miał. Pytanie, czy lepiej cierpieć z nadmiaru, czy niedostatku wiedzy. Dla mnie odpowiedź jest prosta, a jeśli ktoś myśli inaczej, to na pewno znajdzie sobie ciekawsze zajęcia. Może siostry Godlewskie coś nowego nagrały i trzeba odsłuchać?

Dalej jest ciekawiej; np. pisze, że kolejność wierszy w relacji nie ma znaczenia.
I to prawda dla modelu relacyjnego.
I nieprawda dla relacyjnej bazy danych, gdzie dla danej relacji (tabeli) zdefiniowano klastrowany klucz główny (clustered primary key), który automatycznie wymusza kolejność fizycznego zapisu wierszy wg wartości klucza.
Ale nie zawsze wymusi odczyt danych z tej tabeli wg porządku indeksu klastrowanego - to trochę zawiłe i mocno zależy od danego silnika bazy danych. Chodzi o kolejność wierszy, które zostaną zwrócone z tabeli bez jawnego pokreślenia porządku przez order by. W takim przypadku np. w MSSQL dane zostaną zwrócone wg kolejności najmniejszego indeksu dla danej tabeli - ponieważ optymalizator wybierze najmniejszy indeks do skanu tabeli, a nie zawsze musi to być clustered primary key.

No więc kolejność wierszy w relacji nie ma znaczenia, a silnik baz danych też zwracają dane w nieokreślonej kolejności. Praktyka przypadkiem zachowuje się jak teoria, a ja jakoś nie widzę, żeby nie było tu coś nie tak.

Także wykład OK, ale... to jest tylko wierzchołek góry lodowej ;-)

Jak każdy wykład z I stopnia studiów.

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0