Da li ti je SQL na raspolaganju. Ovo sto ti treba je pocetnicka stvar, i objasnjenje pise verovatno medju prvim stranama svakog uputstva za SQL. Ako to ne znas, znaci da nisi citao nista o SQL-u, a red bi bio da procitas.

Ako nemas SQL, onda u Delphiju mozes da iskoristis Lookup i Calculated polja u TTable da povezes tabele. Pogledaj u Help.

S obzirom da nisi bas precizno postavio problem, a nisi naveo koja je baza u pitanju (DBMS), dacu ti resenje koje radi na MS SQL-u ili Access-u - onako kako sam shvatio.

hmm, nisi baš najbolje objasnio ali izgleda da si ti opisao tvoje podatke u tabeli1 i tabeli2. Ako je to tačno, onda bi SQL (u Visual FoxPro-u, a verujem i u ostalim DB alatima) izgledao otprilike ovako.

SELECT Tabela1.ime_polja1 AS naziv, SUM(Tabela1.ime_polja2-Tabela2.ime_polja2) AS ukupno FROM Tabela1, Tabela2 GROUP BY Tabela1.ime_polja1

gde su naravno ime_polja1 i ime_polja2 odgovarajuća imena polja ili kolona u tvojim tabelama.

E sad...ovaj upit bi filtrirao podatke tako da bi u krajnji rezultat ušli samo elementi koji se pojavljuju u obe tabele, npr kao kod tebe Naziv1, Naziv2 itd. Međutim ako bi u prvoj tabeli imao elemente Naziv_1, a u drugoj N_aziv1, oni se ne bi pojavili u rezultujućem kursoru.
Rešenje je opet u zavisnosti od toga šta hoćeš da uradiš LEFT, RIGHT ili FULL JOIN

Pozdrav

Ma u pravu ste nista nisam napisao . Koristim DBISAM DBEngine za Delphi (kompletna zamjena za Borland BDE ) . Trebam postaviti SQL za Query kako bi brze dosao do stanja artikala na skladistu ulaz - izlaz.Probao sam , nesto slicno tacnije navedeni kod:


I nije islo pa sam probao



i naravno nije islo. Rezultat jedino dobijem sa ovim kodom, ali takve podatke dalje nemogu upotrebiti( bar da je jos






Imam neke sto scripte sto ebook izdanja , mastering ovo-ono ali sve sto sam pokusao na ovaj nacin ne ide.Ok je to za programski nacin povezivanja tabela ali trebam samo pregled. Naci dio iz ulaz tabele - dio iz izlaz da bi dobio stanje.

Pomozite...


_{[Ovu poruku je menjao codeb.s dana 06.06.2006. u 13:04 GMT+1]}

A ono sto goranvuc napisa ne radi? Moguce je da DBISAm ne podrzava ugnjezdene upite, pa moras razdvojiti na dva, prvo uradis uniju a onda select group by koji izracuna razliku.

Ako imas vise istoimenih naziva, onda ih moras gupisati... Da ti napisem query i za to ili ces moci i sam?

Dejane, sve je to super, ali sta cemo sa nazivima cija je pojava samo u jednoj tabeli? Takodje, na ovaj nacin ce resultset sadrzati vise pojava istog naziva. Koliko se "razumem u politiku" njemu treba za nazive (koji se pojavljuju u prvoj tabeli, drugoj ili obe) dati ukupan saldo.

Biće da je rešenje OUTER JOIN sa GROUP BY

Ako se dublje udubite u problematiku, shvaticete da problemi kod kojih je potrebno da se dva polja iz dve razlicite tabele preslikaju u jedno polje u resultset-u moraju ukljuciti uniju kao resenje problema - dakle, ja ne verujem da tu pomaze bilo kakav join jer treba da dobijemo:

pera, 55
mika, -45
jovan, 100

gde je pera iz prve tabele, mika iz druge, a jovan je u obe tabele.

Ja sam napisao rjesenje gledajuci njegovu strukturu podataka. Dublje u problematiku nisam ulazio, niti imam vremena da nagadjam kako je autor teme zamislio strukturu podataka.

Naravno da ima tu i potpitanja "a sta ako...", pa kad budu navedeni, dacu rjesenje i za njih, ukoliko neko prije mene to vec ne uradi...

I jedni i drugi su u pravu. Ipak probacu jednostavnije. Imam Tabelu ArtikliUlaz sa nrp. Artiklom1 koji je usao u skladiste recimo 3 kom, imam Artikla2 koji je usao recimo 2 kom i imam Artikal3 koji je usao 1 kom.Onda je ponovo (recimo drugi dan), Artikal2 usao 3 kom, Artikal1 2 kom Znaci tabela izgleda nesto kao:
ULAZ
Artikal Kolicina
===== ==========
Artikal1 3
Artikal2 2
Artikal3 3
Artikal2 3
Artikal1 2

Tako nesto imam i na izlazu:
IZLAZ
Artikal Kolicina
===== ==========
Artikal1 1
Artikal2 2
Artikal3 2
Artikal2 1
Artikal3 1

Sada hocu da grupisam sve i iz ULAZ i iz IZLAZ i da dobijem rezultat tj da dobijem:

REZULTAT
Artikal Kolicina
===== ==========
Artikal1 4
Artikal2 2
Artikal3 0


Molim pomoc

Sa union SQL-om ćeš dobiti sve transakcije(promene) koje su se desile za sve artikle u obe tabele, a sa GRUOP BY ćeš ih sabrati. Ako to ne radi u jednom selektu(a trebalo bi), onda razdvoj na dva kao što reče Broker.

Dakle, sve sam ti rekao, broker ti je dodatno pomogao, a ako ga nisi razumeo treba da napravis View u tvojoj bazi i onda da na tom View-u kao tabeli uradis GROUP BY, tj. ono sto sam ti ja napisao u jednom SQL izrazu treba da rastavis na SELECT iz unije koja je sacuvana u bazi kao View (ako je to u tvom slucaju moguce).

Pozdrav, i probaj da nas postedis detektivskog posla u buducnosti i problem predstavis sa svim neophodnim informacijama - nemoj nista da podrazumevas, ovo je generalni forum "Baze podataka".

Malo sam se informisao oko tvog DBISAM-a za DELPHI 7.0 i mogu ti reci da se nisi usrecio - ne podrzava upite koji referenciraju druge upite, tj. vrlo malo imas prostora da problem resis preko jednog SQL upita. Kako sam video iz njihove dokumentacije, mogao bi da za deo upita koji se odnosi na UNION odradis SELECT INTO u privremenu tabelu, pa da onda za nju odradis GROUP BY upit kojim bi dobio zeljeni rezultat.
Za ozbiljniju problematiku preporucujem ti neki DBMS koji ima mocniji DML od ovog kojeg trenutno koristis.

_{[Ovu poruku je menjao goranvuc dana 06.06.2006. u 23:23 GMT+1]}

Sumnjam d amu treba nesto ozbilnjije, sudeci po tome da cak nema ni ID_ARTIKLA u tabelama.

:)

Ok hvala. Probacu da se prebacim na FIB ili IB izgleda da sa ovim necu nista uspjeti.
Sto se tice Artikla_ID , tabele koje sam postavio kao primjer imaju i primarni i dva sekundarna kljuca , i posjeduje polje Artikal_ID koje se u mom slucaju zove Sifra_Artikla.

Puno hvala oko pomoci!!!

Ne znam sta je u pitanju, neki zadatak ili posao u firmi, ali struktura



nije bas najsrecnije resenje. Deluje kao robno. Imam osecaj da prelazis na nekog starijeg sistem na delfi, tj "prepisujes" staru aplikaciju na windows. I sada bi da koristis bazu. Znaj da svaka baza racionalnije koristi prostor nego to sto si do sada radio. Zato lepo napravi strukturu

KARTICE (PROMET)
===========
Artikal
Kolicina_ulaza
Kolicina_izlaza
...
i ostalo kao datum, dokument, ...

pa ces sa jednim

select distinct artikal, sum(kolicina_ulaza - kolicina_izlaza) from kartice

dobiti lager u jednom potezu. Ili jos jednostavnije ako napravis VIEW.

Pa, oko ovoga bi mogla da se rasplamsa zesca debata :) Ovo je, koliko ja znam, cesce resenje - svaki tip poslovnog dokumenta ima svoje odgovarajuce tabele (najcesce tipa master-detail), a ono sto ti predlazes je "clipperasko" resenje. Njegovo resenje uvek moze da se svede (preko union view-ova, stored procedura) na resenje gde je kompletan promet u jednoj tabeli, a obrnuto MALO TEZE.



Pa ne bas sa DISTINCT, pre sa GROUP BY, zar ne?

sorry, ne znam sta mi bi, treba

select artikal, sum(kolicina_ulaza - kolicina_izlaza) from kartice
group by artikal

hmm, Sve naravno zavisi od toga kako se isprojektuje baza podataka, ali uvođenjem tabele "Vrsta Dokumenta" i stavljanjem ID_VD-a kao spoljnog ključa u tabelu transakcija (ili prometa) smanjio bi se broj tabela.
E sad pitanje je da li ova "normalizacija" izdvajanjem VD-a u posebnu tabelu može da pokrije sve specifičnosti, jer na primer, da li se kod maloprodaje, veleprodaje, internog prenosa, materijalnog i proizvodnje - cena stavlja u jedno polje ili bi morao imati više polja.




A pošto je View u stvari SQL upit, koji je u tvom slučaju spojio više tabela, jednako je lako View-om iliti SQL-om izvaditi promete odgovarajućih Vrsta dokumenata iz zajedničke tabele prometa na osnovu spoljnog ključa.

Zavisi od toga šta se hoće postići.

Pozdrav

Kao sto sam i rekao:

Toliko sam se puta raspravljao sa raznim prijateljima i neprijateljima oko ovoga, pretresli smo sve aspekte i jednog i drugog resenja, da bi na kraju dosli do solomonskog: "Neka svako radi kako mu najvise odgovara!", tako da sam postao prilicno indeferentan prema ovom problemu - ja sam se opredelio, ali moram priznati da ponekad koristim kombinaciju oba resenja.

Ne bih ni reagovao da nije draganescu naveo resenje koje zastupam kao "zastarelo resenje", posto mi se cini da je stvar obrnuta. Poenta je da i jedna i druga varijanta "rade posao".

@goranvuc nisam nigde tebe pomenuo, mislio sam na prvu poruku

Koliko sma shvatio na pocetku, autor verovatno prelazi na delfi ali pokusava da zadrzi neku staru bazu, mada je diskutabilno da li je DBISAM sistem baza.

Jos se pomalo bakcem kliperom i tamo je obicno bolje da ima vise malih tabela sa prometom (ulaz, izlaz) pa se po potrebi prepise/sastavi u jednu sto je prakticnije za neke poslove. Prostor se u ovom slucaju koristi zaista neracionalno, indeksi nezavisni, sto se mogu smatrati kao veliki nedostaci. Ali to radi godinama i u svoje vreme je bilo na neki nacin revolucionarno.

Ali kod baza je u principu bolje imati jednu veliku (prometnu) tabelu i nekoliko maticnih. Nema onih problema sa rasipanjem prostora i nonzistentnoscu podataka.

To sam u stvari hteo da porucim autoru, sto je prakticno i on zakljucio u nekom prethodnom postu.

Dizajn tabela, stil pisanja i slicno je toliko individualno, vazno je da se stigne do resenja. Da, i ja smatram da je najbolje ono sto znas. Sta god da je.

Hm, ne bih se bas slozio s tim. Naime, trenutno radim na optimizaciji jednog programa, koji obradjuje (SELECT, INSERT, UPDATE, DELETE) podatke iz jedne glomazne tabele sa oko 50-ak kolona. Tabela sadrzi i podatke unazad nekoliko godina, tako da je vec samo ta jedna tabela zauzela oko 50 GB prostora. Da ponovim - jedna jedina tabela zauzima 50 GB prostora. E, sad zamisli select nad tom tabelom, rebuild indexa i neku slicnu operaciju...

Trenutno smo razbili tu tabelu na jednu glavnu i nekoliko sporednih tabela, koje smo medjusobno povezali Foreign kljucevima i par lookup tabela. E sad, ovu glavnu tabelu smo jos dodatno particionisali po godinama i subparticionisali po mjesecima. Da vidis kako sve brzo i bajno funkcionise. Da ne spominjem opcije za PARALLEL upite, za dodavanje i uklanjanje particija i subparticija i td.

Slazem se. Svaka namjena zahtjeva drugaciji pristup i samim tim drugacije rjesenje. Kao sto u osnovi nije isto da li imas OLTP sistem ili imas Data Warehouse sistem, tako nije isto da li ces koristiti jednu glomaznu tabelu ili vise manjih.
Ali kao sto rece Larry Wall, autor Perla - "There's more then one way, to do it."

Ma znam, nije bilo nista licno, samo se dopisujemo :)

Vidis da si naceo prilicno skakljivu temu: "Kako projektovati baze podataka iz problematike poslovne dokumentacije - flat tabela ili specijalizacija?" Ovo je vecna tema.