Ali ljudi moji... ne bih da zvucim "nacitano" ovde svima na forumu, ali niko vas ne tera da pisete SQL upite vec da nacrtate dijagrame, znaci plan kako bi se baza organizovala, kako bi se tabele ukomponovale na najbolji nacin. I ja sam pravio razne gluposti u startu, ali Vand...
Kako ce id_zaposlenog da bude varchar? Ako radis sa brojevima, zasto koristis varchar kao tip podatka koji ces cuvati u bazi?
UVEK koristite iste tipove u jednoj tabeli i drugoj na koju vodi FK. Ako je bigint, onda je bigint, nema integer obican da se stavlja, kamoli tekstualni podatak.
Niste svesni toga, na 10 redova, sve ce da radi za par milisekundi, na 1k redova par desetina ms, a onda najednom dodje par miliona redova i ode sve dodjavola sa par losih joina i where-ova...
Gledajte na to ovako, narodski objasnjeno:
PK i FK posmatrajte kao REFERENCE ka nekim nezavisnim entitetima - plata, zaposleni, itd. Brojevi sluze da oznace samo KO JE TO (PK) ili CIJE JE TO (FK).
Nista sem toga!
Znaci imate zaposlenog 1. On je primio 12 plata. Svih 12 plata ce imati FK "zaposleni_id" = 1. Zaposleni ne treba da ima dodatnu kolonu za referencu ka platama, uvek je dovoljno imati samo PK u prvoj tabeli ako je ovakav princip relacije.
I ovo nije schema, ovo je baza, scheme su nesto drugo.
Mozda je problem sto je u sve ovo ukljuceno vise entiteta i tabela sa porukama zbunjuje ljude. Morate da razmislite da li je neki entitet zavisan od drugog.
Da li je poruka zavisna od plate? Nije. Da li treba da ima referencu ka plati? Ne treba. Ako nekim slucajem i treba, kako da nadjem tog zaposlenog ciju platu gledam i vidim neku poruku, kako to da vidim? Lako. Pogledam kome pripada plata, nadjem tog zaposlenog. Onda od tog zaposlenog iscitam poruke.
Sto se tice ovih daljih pitanja, ovde je zadatak vec "nedovoljno objasnjen". Ti u idealnom slucaju, kako ja volim da radim, nikad neces "hardkodovati" tipove zaposlenja. Imao bi novu tabelu "tipovi_zaposlenja" gde bi imao (id(int)|tip_zaposlenja(varchar)) i onda to vezao preko stranog kljuca, za recimo platu.
Hteo sam da kazem da se "tip zaposlenja" cuva u tabeli "zaposleni", ali zaposleni moze da promeni tip zaposlenja, i onda se ne bi videlo da li je u trenutku primanja te plate bio zaposlen ili ne. To je jos jedna stvar koju treba imati na umu.
Cela poenta price... sto manje tabele, sto vise stranih kljuceva, mnogo lakse se barata s podacima. I nemoj da vas varaju da cuvate slike u bazi :)
Ovo je najmanji problem za sve vas da vam nacrtamo, ali necete nista nauciti iz toga. Ako je vec ovo "finalni zadatak" ili sta god, krenite sa prostijim stvarima, pa onda sirite dalje. Napravite prvo tabelu "dopisivanja" zaposlenih, manite se plata u potpunosti. Onda posle im dajte plate :)
Plata pripada zaposlenom.
Poruka pripada dvoma zaposlenih (jedan id za onog sto salje, jedan id za onog sto prima).
Nigde ne cuvajte duplo podatke. Ako u jednoj tabeli postoji ID zaposlenog, ne unosite njegovo ime u tabelu gde postoji FK ka tom zaposlenom.
THE ONLY EASY DAY WAS YESTERDAY