Mala pomoc oko oduzimanja kolona

[ ksrele @ 28.03.2011. 18:11 ] @

Verovatno je resenje na dohvat ruke ali ga ja nikako ne vidim.
Naime, imam 3 tabele
1. tabela (sifarnik) nekih predmeta (nebitno cega)
2. tabela gde se evidentira svako povecanje broja tih predmeta (mora ovako zbog datuma povecanja i evidencije ko je povecavao [to je zasebna tabela])
3. tabela gde se evidentira svako smanjenje broja tih predmeta.

E sad, prvo sam bio napravio i 4. tabelu gde sam cuvao stanje ovih predmeta ali sam onda dosao do zakljucka da mi se (nekako) stvaraju greske kod obracunavanja tog stanja (bug u kodu, tesko ga je ispraviti zbog lose logike programiranja) pa sam skontao da mi je lakse dobiti stanje predmeta brzim proracunavanjem povecanja - smanjenja.

SQL je ovakav:

Code (sql):

SELECT p.ID_p, p.naziv, (SELECT SUM(kolicina) FROM povecanja WHERE ID_p = s.ID_p) - (SELECT SUM(kolicina) FROM smanjenja WHERE ID_p = s.ID_p) FROM predmeti AS p ORDER BY p.naziv;

 

Problem je u tome sto kada imam povecanje a nemam smanjenje onda dobijem sve nule. Jedino ako se isti predmet pojavljuje i u tabeli smanjenja i u tabeli povecanja onda ce se dobiti prava vrednost stanja...

Ne znam kako ovo da resim... Molim za pomoc.

P.S.
SQLite je u pitanju, ali ES nema podforum za njega.

[ Nikola Poša @ 28.03.2011. 19:50 ] @

A od čega je taj alijas "s", u tim WHERE-ovima gde radiš SUM?

Inače, meni se čini da to treba da se odradi sa malo levih spajanja i grupisanja po id-u predmeta, možda ovako nešto:

Code:
SELECT p.ID_p, p.naziv, SUM(po.kolicina), SUM(sm.kolicina)
FROM predmeti p
LEFT OUTER JOIN povecanja po ON po.ID_p = p.ID_p
LEFT OUTER JOIN smanjenja sm ON sm .ID_p = p.ID_p
GROUP BY p.ID_p

[ bogdan.kecman @ 29.03.2011. 04:54 ] @

unutrasnji select u ovom slucaju mora da vrati samo jedan slog - ako vraca vise od jednog rezultat je "nepoznat"!

kao sto rece kolega .. pogledaj malo http://dev.mysql.com/doc/refman/5.5/en/join.html

[ Shinhan @ 29.03.2011. 07:17 ] @

Ja mislim da ti NULLovi prave problem, probaj recimo:

Code:

SELECT p.ID_p, p.naziv, IF(po.ID_p IS NULL,IF(sm.ID_p IS NULL,0,-SUM(sm.kolicina)),IF(sm.ID_p IS NULL,SUM(po.kolicina),SUM(po.kolicina)-SUM(sm.kolicina))) AS kolicina
FROM predmeti p
LEFT OUTER JOIN povecanja po ON po.ID_p = p.ID_p
LEFT OUTER JOIN smanjenja sm ON sm .ID_p = p.ID_p
GROUP BY p.ID_p

Samo, ne shvatam šta će ti posebne tabele za + i -. Imam i ja sličan problem gde treba da pratim povećanja i smanjenja nečega, ali + i - su mi u istoj tabeli sa signed poljem za količinu, i onda ako mi treba samo smanjenja radim "WHERE kolicina < 0". Mnogo jednostavnije IMHO jer za sumiranje se radi jednostavno SUM(kolicina).

[ ksrele @ 29.03.2011. 09:48 ] @

Offtopic: Vidi, pa moja tema je ipak dospela do servera... Kako ocajno radi ES ovih dana, znaci uzasno. Jedno pola sata sam pokusavao da postavim temu, ali bezuspesno (barem sam ja tako mislio)

Ontopic: Ljudi, hvala vam na odgovorima ali sam nekako sam izburlao resenje. Na zalost tacan kod mi je na drugom racunaru pa cu sada samo napamet da objasnim sta je problem.
Alias "s" jeste visak zaista, to je ostalo ot tabele "stanje", treba sada da pise "p.ID_p" umesto "s.ID_p".

Resenje sam nasao koriscenjem funkcije COALESCE, naime, kod predmeta koji nemaju red (ID) u "smanjenjima" ili "povecavanjima" izlaz iz tih SUB-SELECT-ova je NULL i onda se nikako ne moze oduzeti NULL od brojcane vrednosti jer ce opet vratiti NULL.

Kod sada izgleda ovako nekako:

Code (sql):

SELECT 

    p.ID_p, 

    p.naziv,

    CAST(

       COALESCE((SELECT SUM(kolicina) FROM povecanja WHERE ID_p = p.ID_p),0) - COALESCE((SELECT SUM(kolicina) FROM smanjenja WHERE ID_p = p.ID_p),0)

       AS REAL)

   FROM predmeti AS p 

   ORDER BY p.naziv;

Inache, primetio sam i greske u baratanju brojnim vrednostima ukoliko ne uradim CAST u REAL (iako je polje u tabli vec REAL).

[ Shinhan @ 30.03.2011. 08:35 ] @

Nice, naučio sam nešto novo, nisam znao za Coalesce.

Nego, zašto koristiš Real? Kako to da količina nije ceo broj?

[ VladaSu @ 31.03.2011. 11:48 ] @

Citat:

Shinhan: Nice, naučio sam nešto novo, nisam znao za Coalesce.

Nego, zašto koristiš Real? Kako to da količina nije ceo broj?

Pola kilograma krompira. :)

[ ksrele @ 31.03.2011. 17:44 ] @

Pa da, covek se uci dok je ziv :)
A Real bas zato sto nisu sve kolicine celi brojevi. Prosto. Ja sam u primeru naveo da se radi o "predmetima" a to moze biti bio sta...

[ bogdan.kecman @ 31.03.2011. 22:37 ] @

ako ces da ih poredis, porazmisli o decimal umesto real

[ Shinhan @ 01.04.2011. 13:32 ] @

Nadam se samo da to nisu finansijski podaci. Korišćenje REAL za finansije je jedna od početničkih grešaka.

Ne mogu da zamislim ni jedan slučaj da REAL može biti bolja ideja od DECIMAL za snimanje podataka u bazu.

[ ksrele @ 01.04.2011. 14:20 ] @

Da ponovim za one koji nisu procitali moju prvu poruku: u pitanju je SQLite ali [ES] NEMA podforum za njega pa sam zato pitao ovde, a ako procitate ovaj link videcete da SQLite nema DECIMAL tip-a.

A mogu li ja da iskoristim priliku da pitam u cemu je razlika? Ja u VB aplikaciji koristim Decimal tip promenjivih.

[ bogdan.kecman @ 01.04.2011. 15:06 ] @

iskreno nisam imao pojma da sqlite nema decimal ... nadam se da im je implementacija za real kao sto ostali implementiraju decimal (real je jedan veliki "pain in the ..") elem, sto se "podforuma" tice, ima podforum baze podataka i tamo je i m$sql i oracle i pgsql i sqlite i firebird i sta god ti padne napamet. samo je mysql odvojen u zaseban podforum od svih njih. Tako da ljude sa sqlite iskustvom uvek mozes da navatas tamo :) ... mada .. sve je to ...

sto se razlike decimal i real tice .. najveci problem je u poredjenju .. da li je 3.33333 == 3.3333333333 ? da li je 0.0000000001 == 0? da li je 10000000 + 0.0001 > 10000000 ? .. u 90% slucajeva ce se tvoj odgovor (sta ocekujes) razlikovati od onoga sto ce rdbms da vrati .. zato sto real radi tako sto imas mantisu i exponent dakle ti imas n "znacajnih cifri" i pomeras ih levo desno od zareza tako da ne postoji broj 100000000000000.001 ... kod decimal tipa znas tacno koja ti je preciznost, tj nema exponenta vec je mantisa "vezana" za lokaciju definicijom kolone (dakle ako imas decimal (10,3) na primer to ti je mantisa od 10 karaktera i zakucan exponent na -3) tako da se u tom slucaju uvek ono sto mislis da ce biti rezultat poredjenja poklopiti sa onim sto ce baza uraditi

[ ksrele @ 01.04.2011. 21:53 ] @

Aha, kapiram.

Mislim da se moze definisati tako, kao DECIMAL(10,3) ali koliko sam shvatio da on tu brojnu vrednost smesti kao neki specijalni INTEGER ili REAL... nisam jos to dobro provalio. Inache si skroz upravu to za poredjenje. Sve te kontam, ali nikad nisam radio poredjenja REAL brojeva pa nisam imao tih problema, ali lepo da znam za ubuduce.
Hvala.

[ bogdan.kecman @ 02.04.2011. 09:41 ] @

nije taj tip podataka tu "za dzabe" ... svaki ima svoje gde radi bolje posao .. fora je samo znati kako se tacno ponasa ... nista drugo ... 80% "saveta" su tu vise zato sto je jednostavnije reci coveku "nemoj to tako" nego mu drzati 2 godine obuku o strukturi podataka da bi on svatio onih 2% primera kada to moze i ima smisla