Logika povezivanja dve SQL tabele

[Neky]

Hejhej drugari,

naleteo sam na mali problem u ovom mom projektu kroz koji učim. Problem je sledeći: u bazi se nalaze dve tabele, neka se zovu tab1 i tab2. Tab1 sadrži X redova sa Y kolona. Jedna od tih kolona je broj BR123. Tab2 sadrži M redova sa N kolona. Jedna od tih kolona je takođe broj BR123

Ono što ja treba da uradim je da iz Tab1 uzmem kolonu IME, a iz Tab2 kolone broj,datum,vreme. Zajednička im je kolona broj, taj broj je isti.

Šta raditi u ovakvim slučajevima? Za kod ću se snaći, nego me interesuje logika. SQL nisam učio u školi, nemam nikakvo predznanje. Uhvatio sam se projekta i kroz njega učim.

[voodoo_]

Kad ti trebaju podaci iz više tabela povezanih zajedničkim ključem, logika je sledeća: prilikom jednog upita u kome si obuhvatio više tabela, SQL baza bukvalno pravi kombinacije svakog reda iz jedne i svakog reda iz druge baze, pa onda rezultate filtrira na osnovu uslova koji si postavio u upitu.

Dakle kad bi stavio upit bez uslova, kao npr

SELECT Tab1.Ime, Tab2.broj, Tab2.datum, Tab2.vreme
FROM Tab1, Tab2

(valjda je ovo sintaksa, zaboravio sam)

dobio bi rezultat sastavljen od N redova gde ide prvo ime iz tabele 1 i sve moguće vrednosti broja, datuma i vremena iz tabele 2, pa još N redova gde je drugo ime iz tabele 1 pa sve moguće vrednosti broja, datuma i vremena iz tabele 2, itd.

Zato ubacuješ uslov,

SELECT Tab1.Ime, Tab2.broj, Tab2.datum, Tab2.vreme
FROM Tab1, Tab2
WHERE Tab1.BR123 = Tab2.BR123

i to će ti isfiltrirati samo redove u gde se vrednosti BR123 u obe tabele poklapaju. Međutim tu verovatno i dalje nećeš shvatiti suštinu primarnih ključeva i relacija u relacionim bazama. Mislim da učenje relacionih baza samo na osnovu jednog projekta i bez teorijske potpore nije pametno. Najtoplije preporučujem neku od knjiga koje kreću od nule, kao na primer SQL All-in-One for Dummies, gde ćeš pokriti osnove i posle neće biti zabuna.

obrisan link

Molim moderatore da zažmure na oba oka, očigledno se radi o studentu koji verovatno nema tek tako 2 hiljade din da pljune na knjigu.

[Neky]

Skinuo, hvala, obriši link da ne pravimo probleme. Javiću se kad pročitam post par puta.

[Neky]

To je to, radi. Prilagodio sam upit tabelama koje koristim, i python vrati lepu listu sa kojom mogu da se igram. Jupiiiiiii.

Hvala mnogo voodoo_ !

[irreal]

a kada malo procitas knjigu i udjes u stos, where uslov ces koristiti za realno filtriranje podataka po nekim kriterijuma, a JOIN keyword za spajanje vise tabela. koriscenje JOIN-a daje mnogo citljiviji kod (filter je, npr, daj sve starije od dve nedelje, a ne spoji tabele smisleno), daje ti MNOGO vecu fleksibilnost (ponekad ce ti zatrebati i left/right, inner/outer join-ovi)

ali, sve u svoje vreme, samo polako i korak po korak. materija je prilicno jednostavna ali samo ako se pravilno uci. kao i mnoge stvari, ako udjes u sve na prepad zbunices se i iznervirati :)

[Neky]

Da ne otvaram novu temu, pošto je vezano za istu bazu, i tabele.

Tabela je kreirana ovako:

CREATE TABLE predmeti (id integer primary key autoincrement, ime string,brPredmeta string unique,statusStr string,ostaleStr string,sud string, sudskaJed string,sudskiBr string,sudija string,datumTuzba string,vrednost string,datumRasprave string,vreme string,tipPostupka string,statusPredmeta string,napomena string,zaduzen string,datumZaduzenja string,arhiviran string);

Znam da je pogrešno ne ograničiti dužinu upisa u bazu, ali sam taj deo ograničio preko forme kroz koju se unosi (lineEdit elementi i slično)

Kod koji se ne izvrši kako treba je :

UPDATE predmeti SET arhiviran = "ARHIVIRAN" WHERE brPredmeta ="BR12";

Izvrši ga (ne izbaci nikakvu grešku), ali ako uradim select:

select arhiviran from predmeti where brPredmeta="BR12";

dobijem prazan string, kao da ništa nisam uradio. To je slučaj sa svim predmetima koje imam, nezavisno od njihovog broja.

Gde grešim :/

:edit:

Čini mi se da ima veze sa tim što se ime kolone i vrednost u tom polju ne razlikuju (arhiviran, ARHIVIRAN)

:edit2:

Da, bio sam u pravu. Ako u kolonu arhiviran unesem "DA" sve prolazi bez problema.

[Todors]

Ne znam koju bazu koristiš, ali u sql-u ne postoji tip string i naredba autoincrement, ali nema veze.

Ovaj updejt će ti proći i ako ti u bazi ne postoji podatak "br12", tj. neće ti izbaciti ni jednu grešku, ali će ispisati "0 row(s) affected".

Tako da ja sumnjam da ti se to upravo i desilo i iz tog razloga ti select nije vratio ni jedan rezultat.

SQL ne razlikuje velika i mala slova tako da je sve jedno da li ćeš da napišeš br12 ili BR12. Imaće isti efekat.

Samo bih ti još preporučio da ipak vodiš računa o poljima koje kreiraš u bazi, tj. da li je nulabilna, veličina stringa, relacije i tome slično, jer relacioni model koji napraviš u bazi treba da bude prenet u klasni model koji se u suštini ne razlikuje mnogo.

To ti govorim iz razloga što je ova praksa (pa i teorija) ključna u projektovanju velikih sistema. Jer zamisli na primer da napraviš bazu sa 120 tabela koje u proseku imaju po 50tak kolona. Ako u kodu definišeš validaciju za svaku kolonu ponaosob, desiće ti se da napraviš mnogo previda i da će ti pucati aplikacija a da toga nisi svestan. Pritom nećeš moći da pronađeš gde je problem (ovo ti govorim iz iskustva). Da ne kažem da ako neki drugi programer npr. alteruje 50tu tabelu i 50tu kolonu, tako da ne bude više nulabilna. Puknuće ti aplikacija, a ti ćeš izgubiti minimum 3 dana da pronađeš gde je problem.

Kreni od toga da ti je baza temelj aplikacije. Ako ti je temelj odličan i aplikacija će ti biti odlična, a ako je model loš ni jedan programer na svetu neće uspeti da napraviti valjanu aplikaciju.