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??
Pełna wersja: PRIMARY KEY
Cytat
Czy możliwe jest niemieć w tabeli żadnego pola PRIMARY KEY??
oczywiscie ze mozliwe po prostu nie nadajesz zadnemu polu primary key
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 ?
A kto porównuje: ano baza danych, czyli w mojej opini najsłabsza (najbardziej swpowoliająca całość...) częśc aplikacji sieciowych 
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 ?
A kto porównuje: ano baza danych, czyli w mojej opini najsłabsza (najbardziej swpowoliająca całość...) częśc aplikacji sieciowych
Cytat
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.
Cytat
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 ? A kto porównuje: ano baza danych, czyli w mojej opini najsłabsza (najbardziej swpowoliająca całość...) częśc aplikacji sieciowych
A kto porównuje: ano baza danych, czyli w mojej opini najsłabsza (najbardziej swpowoliająca całość...) częśc aplikacji sieciowychpole 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 :!:
No nie, ale ja jestem maniak optymalizacji 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ą 
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ą
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.
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.
Moim zdaniem nalepiej robic jako PRIMARY_KEY osobny rekord nazwany np ID INT(3). Latwiej sie na tym operuje a baza nie jest obciazona.
To sa wlasnie sztuczne klucze, o ktorych pisal halfik, czyli takie ktore nie przechowuja zadnych danych, a jedynym ich zadaniem jest bycie kluczem.
Cytat
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
(65535 rekordow chyba wystarczy w wiekszosci zastosowan )
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.