PRIMARY KEY Opcje

[skubekk]

Mam taką o to baze:

KLASA
rocznik | klasa | wych|

Uczniowie
rocznik | klasa | imie | nazwisko |

W tabeli KLASA PRIMARY KEY są rocznik i klasa.

Niewiem jaki mam dać PRIMARY KEY dla tabeli UCZNIOWIE ponieważ w jednej klasie (teoretycznie) moze byc 2 uczniów o takim samym imieniu i nazwisku. Myślałem nad dodaniem pola ID ale niejest ono mi do niczego potrzebne. Czy możliwe jest niemieć w tabeli żadnego pola PRIMARY KEY??

[Bags_Bunny]

Czy możliwe jest niemieć w tabeli żadnego pola PRIMARY KEY??

oczywiscie ze mozliwe po prostu nie nadajesz zadnemu polu primary key (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

[halfik]

a co do klucza głównego: jak masz klase, to znacy że jest np. 5A, a w klasie uczniów i każdy z nich ma numerek w dzienniku, zatem dlaczego z tej pary nie zrobić klucza?

P.S sztuczne klucze są całkiem całkiem, ja tylko takich używam. Z prostej przyczyny: szybciej porównać w liczby całkowite niż np. 2 ciągi po 10 znaków każdy nie ? (IMG:http://forum.php.pl/style_emoticons/default/snitch.gif) A kto porównuje: ano baza danych, czyli w mojej opini najsłabsza (najbardziej swpowoliająca całość...) częśc aplikacji sieciowych (IMG:http://forum.php.pl/style_emoticons/default/tongue.gif)

[skubekk]

a co do klucza głównego: jak masz klase, to znacy że jest np. 5A, a w klasie uczniów i każdy z nich ma numerek w dzienniku, zatem dlaczego z tej pary nie zrobić klucza?

Na początku roku każdy uczeń dostaje numer w dzienniku. Jeśli do klasy w ciągu roku dochodzi nowy uczen to dostaje ostatni numerek w dziennku, a ja chce zeby uczniowie byli posegregowani alfabetycznie według nazwisk.

P.S sztuczne klucze są całkiem całkiem, ja tylko takich używam. Z prostej przyczyny: szybciej porównać w liczby całkowite niż np. 2 ciągi po 10 znaków każdy nie ? (IMG:http://forum.php.pl/style_emoticons/default/snitch.gif) A kto porównuje: ano baza danych, czyli w mojej opini najsłabsza (najbardziej swpowoliająca całość...) częśc aplikacji sieciowych

pole ROCZNIK ma typ YEAR czyli np: 1999
pole KLASA ma typ CHAR(1) np: B

więc moim zdaniem takie klucze nieobciążają zbytnio bazy danych :!:

[halfik]

No nie, ale ja jestem maniak optymalizacji (IMG:http://forum.php.pl/style_emoticons/default/tongue.gif) A chyba naturalne jest, że komp szybciej porówna (język do wyboru) 2 liczby całkowite niż stringi, bo "1999A" to już string. Zresztą sztuczne klucze jakieś takie milsze są (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)

[DeyV]

wykorzystanie kluczy dodatkowych jest bardzo przydatne z jeszcze innego powodu.
Znanie łatwiej jest napisac skrypt php, podający id wiersza który chcemy edytować, usuwać, itp. niż kombinowac z kluczami złożonymi, które na dodatek w różnych tabelach będą miały zupełnie inne nazwy.

[zuku]

Moim zdaniem nalepiej robic jako PRIMARY_KEY osobny rekord nazwany np ID INT(3). Latwiej sie na tym operuje a baza nie jest obciazona.

[FiDO]

To sa wlasnie sztuczne klucze, o ktorych pisal halfik, czyli takie ktore nie przechowuja zadnych danych, a jedynym ich zadaniem jest bycie kluczem.

[Kinool]

Moim zdaniem nalepiej robic jako PRIMARY_KEY osobny rekord nazwany np ID INT(3). Latwiej sie na tym operuje a baza nie jest obciazona.

no jesli juz to mala optymalizacja by sie przydala

typ:SMALINT atrybut: UNSIGNED (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) (65535 rekordow chyba wystarczy w wiekszosci zastosowan (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg) )