Właśnie zaczynam swoją "przygodę" z MySQL i ogólnie z RDBMS. Po lekturze trzeciego wydania "PHP i MySQL Tworzenie stron WWW - Vademecum profesjonalisty" autorstwa Luke'a Welling'a i Laury Thomson mam parę wątpliwości.

Po pierwsze, czy jeżeli utworzę taką tabelę:

[SQL] pobierz, plaintext 
Klienci ([u]KlientID[/u], Nazwisko, Adres, Miejscowosc)
[SQL] pobierz, plaintext 

a następnie taką:

[SQL] pobierz, plaintext 
Zamowienia ([u]ZamowienieID[/u], KlientID, Wartosc, DATA)
[SQL] pobierz, plaintext 

to czy kolumna KlientID w drugiej tabeli automatycznie staje się kluczem obcym?

Pytanie drugie. Co się stanie, jeżeli stworzę dwie tabele jak poniżej (i czy jest to w ogóle dopuszczalne?):

[SQL] pobierz, plaintext 
AktywniKlienci ([u]KlientID[/u], Nazwisko, Adres, Miejscowosc)
[SQL] pobierz, plaintext 

[SQL] pobierz, plaintext 
NieaktywniKlienci ([u]KlientID[/u], DATA)
[SQL] pobierz, plaintext 

a następnie do bazy dodam jeszcze jedną...

[SQL] pobierz, plaintext 
Zakupy ([u]ProduktID[/u], KlientID)
[SQL] pobierz, plaintext 

Który z kluczy podstawowych (z której tabeli) stanie się kluczem obcym w ostatniej?

I na koniec, ostatni problem. Czy po utworzeniu tabel:

[SQL] pobierz, plaintext 
Zakupy1 ([u]ProduktID_1[/u], Dane)
[SQL] pobierz, plaintext 

[SQL] pobierz, plaintext 
Zakupy2 ([u]ProduktID_2[/u], Dane)
[SQL] pobierz, plaintext 

taka sama nazwa dla kolumny tj. Dane w obu tabelach może przysporzyć w późniejszej pracy z bazą jakowyś problemów? Jednym słowem, czy lepiej jest stosować unikalne nazwy dla poszczególnych kolumn różnych tabel, czy może nie ma po co sobie tym głowy zaprzątać. Oczywiście, mówię tu o polach nie będących kluczami podstawowymi/obcymi, a jedynie o "zwykłych" kolumnach.

Ad. 1) Nie. Musisz jasno przekazać MySQL, że kolumna KlientId z tabeli XXX jest kluczem obcym
Ad. 2) Zły projekt bazy. Powinna być jedna tabela - klient - i ona powinna zawierać kolumnę: aktywny (TINYINT)
Ad. 3) Jeżeli występuje niejednoznaczność w nazwach tabel, to w przypadku, gdy dochodzi do sytuacji, gdzie nie można automatycznie stwierdzić o którą kolumnę chodzi podajesz jej nazwę poprzedzoną nazwą tabeli, np.: Zakupy1.Dane, Zakupy2.Dane

Ad. 1) W takim razie, jak to zaznaczyć, że KlientID byłby kluczem obcym w tabeli Zamowienia?
Ad. 2) Właściwie, to miał być tylko przykład - nazwy tabel są zupełnie przypadkowe. Chodziło mi o to, czy jest możliwa sytuacja taka, że dwie tabele mają klucze podstawowe o tych samych nazwach, przypuśćmy "ID".

Ad. 1) Manuala przepisywać nie będę: http://dev.mysql.com/doc/refman/5.1/en/inn...onstraints.html
Ad. 2) Jak najbardziej tak.

Ad. 1) Nawet nie śmiem prosić A tak na poważnie, trochę mnie to zdziwiło, gdyż w książce przytoczonej w pierwszym poście nie było to zaznaczone. Klucz obcy to było samo pojawienie się klucza podstawowego w innej tabeli, tak jakby ten "status" był przyznawany automatycznie. Swoją drogą autor sam sobie przeczy skoro bodajże w następnym rozdziale mówi o maszynach zapisu MyISAM oraz InnoDB wspominając, iż InnoDB obsługuje klucze obce, w przeciwieństwie do MyISAM - który to jest jednak domyślnym typem tabel dla MySQL. Mówię tak, ponieważ przy schemacie bazy jak również w samym kodzie nie było żadnej linijki zmieniającej typ tabeli na InnoDB...

Wniosek: nie ucz się z tego badziewia, tylko używaj dokumentacji. Dużo dalej zajedziesz.

Jeszcze rok temu, jak dokonywałem zakupu tej pozycji, nic nie wskazywało na to, że może się w niej coś takiego znaleźć. Bestseller Helion, wybór czytelników CHIP jako produkt roku 2005, poza tym same pochlebne komentarze we wszystkich serwisach które przeglądałem. No cóż. W każdym razie dzięki Crozin. Pomógł.

@erix: pozwole sie nie zgodzic

@falcone:


Bo tak jest w rzeczywistosci, dodanie FOREIGN KEY sprawia ze zwiazki miedzy tabelami sa kontrolowane, np. nie dodac komentarza do nieistniejacego posta itp. ale bycie kluczem obcym to po prostu wskazywanie wartosci klucza glownego z innej tabeli, a nazwa tej kolumny moze byc inna niz klucza glownego, np.

tabela
user ( id, name, email, .. )
message ( id, title, body, sender_id, recipient_id )

gdzie sender_id i recipient_id wskazuja na user.id


BTW. Mozna skonfigurowac mysql tak zeby myisam nie byl domyslnym enginem. Nie zmienia to faktu ze w ksiazce powinno byc to od razu wyjasnione i tabele powinny byc tworzone z okresleniem typu enginu aby czytelnik niczego nie musial sie domyslac i aby skopiowany kod dzialal u niego od razu, i na podstawie tylko tego kodu, a nie jakichs nieopisanych domyslnych ustawien.