Witam. Trochę się naczytałem o tych wszystkich relacjach jeden do jednego, jeden do wielu i wiele do wielu. Ale nasunela mi się wątpliwość. Otóż, mam 3 tabele:

-klienci
-czesci

-zamowienia

W tabeli zamowienia tworze liste zamowien kazdego klienta pobierajac dane z tych dwoch tabel wyzej. Czyli, aby zrobic relacje jeden do wielu, co musialbym zrobic? Ustawic klucze podstawowe w w tabelach klienci i czesci oraz ustawic kolumny z kluczem obcym w tabeli zamowienia, w ktorych sa wykorzystane dane z tabeli klienci i czesci?

Oraz drugie pytanie, jesli zle ustawie klucze obce, bedzie to mialo wplyw na poprawnosc dzialania bazy czy tylko na jej efektywnosc?

Ja to widzę tak:

Alternatywne rozwiązanie, możesz wszystkim obarczyć kod PHP poprzez wykonywanie odpowiednich zapytań.

Relacje to co innego a klucze to co innego. Kluczę pozwalają Ci wymusić spójność w bazie danych a relacje przedstawiają sposób i zawartość reprezentowanych danych. Najlepiej ustawić PK w tabelach klienci i części a później zrobić FK w tabeli zamówienia "wskazujący" na te klucze w tych tabelach.

Oczywiście, każda (mniejsza lub większa) nieprawidłowość w jakiś sposób wpływa na poprawność i przede wszystkim szybkość działania danej bazy.

Ok wiec jakbym chcial nalozyc ten klucz obcy w tabeli wypozyczenia, to czy by to wygladalo w ten sposob dla tabel:

[klienci]
-klient_id
-imie
-nazwisko

[czesci]
-czesci_id
-cena
-sztuk

[wypozyczenia]
-wypozyczenie_id
-wypozyczenie_klient
-wypozyczenie_czesci
-data

[SQL] pobierz, plaintext 
 FOREIGN KEY (wypozyczenie_klient) REFERENCES klienci(klient_id) ON DELETE CASCADE ON UPDATE CASCADE;
 FOREIGN KEY (wypozyczenie_czesci) REFERENCES czesci(czesci_id) ON DELETE CASCADE ON UPDATE CASCADE;
[SQL] pobierz, plaintext 

Cos w ten desen? I czy ON DELETE CASCADE ON UPDATE CASCADE zostawic czy mozna tylko ON UPDATE CASCADE? Czy obie delete i update sa nierozlaczne?

na czesci nie powinno byc ondelete cascada a ondelete RESTRICT.
RAczej nie nalezy dopuszczac do sytuacji, gdy ktoś wypozyczy jakąś cześć to potem ona zniknie bo w bazie ktoś sobie ją usunal. Czesc ktora zostala wypozyczona nie ma prawa zniknać z bazy.

No to w takim razie, skoro z bazy nie moze zniknac jakas czesc, to takze i klient nie moze zniknac.

Wiec poprawmy:

[SQL] pobierz, plaintext 
 FOREIGN KEY (wypozyczenie_klient) REFERENCES klienci(klient_id) ON DELETE RESTRICT ON UPDATE CASCADE;
 FOREIGN KEY (wypozyczenie_czesci) REFERENCES czesci(czesci_id) ON DELETE RESTRICT ON UPDATE CASCADE;
[SQL] pobierz, plaintext 

A przy update moze zostac cascade? Czy tez RESTRICT?

No tu już sprawa dyskusyjna i zależy od sytuacji, dlatego też nie czepiałem sie do tej akurat relacji

Zacznijmy od tego, że raczej ID rekordów nie zmieniają się, więc update można olac. Nie mniej jednak jesli już dajemy onupdate to lepiej zrobic restrict, by wymusisz te prawde, iż rekordom ID lepiej nie zmieniac

Ok rozumiem. A co moze byc nie tak, bo wyrzuca mi blad jak robie takie polecenie w myAdminie:

[SQL] pobierz, plaintext 
UPDATE wypozyczenia SET FOREIGN KEY (klient) REFERENCES uzytkownicy(uzytkownik_email) ON DELETE RESTRICT ON UPDATE RESTRICT;
[SQL] pobierz, plaintext 

klucze do tabel dodaje sie przy pomocy ALTER TABLE a nie UPDATE. Wiecej info w manualu

Ok. Super dziala Dziekuje.