 PRIMARY KEY |
| PRIMARY KEY |
Post
#1
|
|
 Grupa: Zarejestrowani Postów: 27 Pomógł: 0 Dołączył: 8.08.2003 Skąd: Częstochowa Ostrzeżenie: (0%) 
 |
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?? |
 |
 
|
 |
|
Post
#2
|
|
 Grupa: Zarejestrowani Postów: 262 Pomógł: 39 Dołączył: 12.04.2004 Ostrzeżenie: (0%)
|
Cytat Czy możliwe jest niemieć w tabeli żadnego pola PRIMARY KEY??
oczywiscie ze mozliwe po prostu nie nadajesz zadnemu polu primary key 
-------------------- rm -rf /*
|
|
|
|
|
Post
#3
|
|
|
Grupa: Zarejestrowani Postów: 259 Pomógł: 0 Dołączył: 17.05.2003 Skąd: Nysa Ostrzeżenie: (10%) 
|
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 
--------------------  "Nie wiedziałem tylko, że Bóg też był na grzybach, gdy majstrował przy wszechświecie" (Janusz Wisniewski) dev: gazeta.ie |
|
|
|
|
Post
#4
|
|
|
Grupa: Zarejestrowani Postów: 27 Pomógł: 0 Dołączył: 8.08.2003 Skąd: Częstochowa Ostrzeżenie: (0%)
|
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 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 :!: |
|
|
|
|
Post
#5
|
|
|
Grupa: Zarejestrowani Postów: 259 Pomógł: 0 Dołączył: 17.05.2003 Skąd: Nysa Ostrzeżenie: (10%)
|
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ą 
-------------------- "Nie wiedziałem tylko, że Bóg też był na grzybach, gdy majstrował przy wszechświecie" (Janusz Wisniewski) dev: gazeta.ie |
|
|
|
|
Post
#6
|
|
 Grupa: Zarząd Postów: 2 277 Pomógł: 6 Dołączył: 27.12.2002 Skąd: Wołów/Wrocław |
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. -------------------- "Niezależnie od tego, jakie masz osiągnięcia, ktoś Ci pomaga..."
|
|
|
|
|
Post
#7
|
|
|
Grupa: Zarejestrowani Postów: 44 Pomógł: 0 Dołączył: 17.04.2002 Skąd: Jastrzębie Zdrój Ostrzeżenie: (0%)
|
Moim zdaniem nalepiej robic jako PRIMARY_KEY osobny rekord nazwany np ID INT(3). Latwiej sie na tym operuje a baza nie jest obciazona.
-------------------- GG: 1331870 | Morecambe Bay
|
|
|
|
|
Post
#8
|
|
 Grupa: Przyjaciele php.pl Postów: 1 717 Pomógł: 0 Dołączył: 12.06.2002 Skąd: Wolsztyn..... Studia: Zielona Góra Ostrzeżenie: (0%)
|
To sa wlasnie sztuczne klucze, o ktorych pisal halfik, czyli takie ktore nie przechowuja zadnych danych, a jedynym ich zadaniem jest bycie kluczem.
-------------------- Brak czasu :/
|
|
|
|
|
Post
#9
|
|
 Grupa: Zarejestrowani Postów: 560 Pomógł: 0 Dołączył: 15.07.2003 Skąd: Kwidzyn Ostrzeżenie: (0%)
|
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 )
-------------------- |
|
|
|
 |
|
Aktualny czas: 21.08.2025 - 18:27 |
