probaj sledeci SQL:



cview select u principu mozes da kreiras kao view ako ti zatreba nesto, on vraca spisak svih partnera i pojedinacnih razmaka izmedju dva ulaza.

@mmix: SQL izraz je Ok, samo me interesuje zasto mora CAST na DATEDIFF. To sam vec video negde i nije mi bilo bas jasno. Deluje mi malo nepotrebno. Ne uzbudjuje me gubitak na brzini zbog toga, vise me smeta sto cini izraz komplikovanijim nego sto bi (mozda?) trebalo.

Da bi ga prebacio u float, da bi posle AVG agregat radio nad float tipom, tj da bi AVG(5, 6) bio 5.50
Kad ne bi bilo castovanja u float AVG bi radio sa int-ovima i zaokruzio rezulat na int, dakle AVG (5, 6) bi bio 6

Hvala, sad je bolje :-)

A zbog čega je potrebno da se dobije tačan broj. Int je tu sasvim svrsishodan. I razlika u danima između dve nabavke je ceo broj, čemu onda računati srednje vreme u danima, časovima, minutima, sekundama...?
Teoretski je to, što si uradio, sasvim korektno ali u datom slučaju je nepotrebno gubljenje vremena. U konkretnom slučaju nabavka bi se vršila posle 5 dana jer onih 0,6 ne znam kako da obračunam tj. da li se nabavka vrši posle podne ili čak i noću.

Pa recimo da se ne slazem jer ni ja ni ti ne znamo gde ce taj broj i kako biti upotrebljen, ti si dao samo jednu najbanalniju primenu.
Medjutim, cak i kad primenis taj tvoj algoritam dovesces do eventualnog praznjejna ili prepunjavanja magacina zbog greske u zaokruzivanju. Recimo da je istorijat isporuka bio {5, 6, 5, 6} tebi ce zaokruzen rezultat rezultat biti 6 i buduca periodika ce biti {6, 6, 6, 6, ....} i sta vise ponovna primena nezaokruzene skripte ce prikazati konvergenciju srednje vrednost ka zaokruzenoj {5.6, 5.66, 5.71, itd. }. U poslovnoj implementaciji to znaci da ce roba svaki drugi put stici sa dan zakasnjenja, sto znaci da se svakih 12 dana magacin umanjuje za dnevnu kolicinu bez da ista bude pokrivena i pre ili kasnije ce rezerva biti ispraznjena. Sa druge strane ako periodiku tretiras nezaokruzenu vec zaokruzujes sledeci datum i pamtis ostatak (sati, minut) onda ce periodika nastaviti da izgleda {5, 6, 5, 6, ... } sto je verodostojnije realnoj situaciji.

Recimo da opet ne čitaš postavljeno pitanje. Moram da te podsetim da je pitanje pokretača teme bilo:



Jasno se vidi da za pokretača teme bitan broj celih dana (pogledaj resultsets koji se zahteva). Tako da izgleda samo ti ne znaš kako će taj broj dana biti primenjen.
Čak se ni kod datuma nabavke ne računa tačno vreme kada je roba nabavljena, stigla, smeštena u magacin, itd... Vodi se evidencija samo i samo datuma.

Ja i dalje ne vidim u cemu je tvoj licni problem, ja sam izneo moje razloge zasto sam ubacio cast u float, ako ti ne odgovara a ti izbaci cast u svojoj aplikaciji, meni ni uz dzepa ni u dzep.

I btw, taj dataset i resultset nisu u sprezi jer je dayspan od 1. u mesecu do n-og u mesecu zapravo n-1 a ne n dana tako da su mu rucne kalkulacije neispravne, al ajde. Njegov resultset me ne interesuje sem kao okviran guide formata podataka jer je njegov zahtev zapravo bio resultset koji mu treba za razradu automatskog narucivanja baziranog na ciklicnosti i to je i dobio. Ako vec hoces da glumis njegovog advokata onda bar pitaj njega sta hoce ili bar procitaj celo pitanje, a posto adopilot-a niko ne drzi vezanog siguran sam da mu advokat ne treba i da ce sam da razjasni i dopuni svoje pitanje ako je neophodno.

Zahvaljujem na brzim odgovorima i dobrim odgovorima
Nažalost posao me malo previše stisnu da bi komentarisao i učestovovao u raspravi
a kući su mi sam opet imao goste.

Skripta radi izuzetno tačno ali nažalos izgleda ne funkcionalno jer je moj uzorak podatak ogroman
oko 300 Dobavljača prema 10 Objekata svaki objekat godišenj ima oko 10 000 Ulaza.
I to sve sada treba kontrolisati sql om.
Malo je preteško sve zahtjeve direkora pohvatati i napraviti neke super automatike
Ukoliko postignemo da računar odradi 50% planiranog posla biti cu na konju.
Trenutno dajem prijedlog kako bi to izgledalo kada bi računar radio pa ću vidjeti kakve će oni imati primjedbe.

Ne znam kakav je slučaj u drugim firmama postao ali mene iz dana u dan sve više izluđuje to što se poslovna politika mijenja iz sata u sat.
I to da sve manje ljudi hoće da se udubi u problem i da razradi sve probleme do detalja. Onda ja moram glumiti nostrodamusa
i govoriti da je to nemoguće po pitanju funkcionalnosti i elana poslovanja.

Lijep pozdrav
Admir

@adopilot
Pokušaj da prosečan broj dana računaš malo drugačije. Pošto imaš veliki skup podataka onda u prvom koraku izdvoji podskup koji je mnogo manji i nad kojim računjanje ide mnogo brže. To znači da:
1. Za svakog dodavljača izvuci datum najstarije i datum najnovije nabavke kao i ukupan broj nabavki u tom periodu i
2. Razliku dana između najnovije i najstarije nabavke podeli sa ukupnim brojem nabavki.

Neko slično, samo prilagođeno, rešenje ja koristim za analizu prometa pojedine robe. Brzina rada nije baš toliko kritična jer se ne radi svaki čas već upit već jednom mesečno, kvartalno, polugodišnje ... I nije problem malo sačekati

Mada što se tiče tvog pravog problema, kako ga ja vidim, mnogo je elegantnije nabavku vršiti onda kada količina robe padne ispod neke zadate količine. Povremeno uradiš analizu prometa i na osnovu toga, a i ostalih parametara koji zavise od politike firme odrediš za svaki objekat i svaku robu minimalnu količinu potrebnu u magacinu. Prostim upitom u stanje i poredeći ga sa minimalnom količinom ti praktično trenutno imaš spisak robe koja treba da se nabavi.