Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.

Da li neko hoce da oproba zube na ovome?

[es] :: Baze podataka :: Da li neko hoce da oproba zube na ovome?

[ Pregleda: 4003 | Odgovora: 9 ] > FB > Twit

Postavi temu Odgovori

Autor

Pretraga teme: Traži
Markiranje Štampanje RSS

Last Man Standing
Misha Kostich
Chicago

Član broj: 3775
Poruke: 101
*.client.attbi.com



+1 Profil

icon Da li neko hoce da oproba zube na ovome?12.05.2002. u 02:37 - pre 243 meseci
Boyz and Girlz:

Evo jednog malo uproscenog problema.

Firma ima klijente i hoce da ih rangira po brzini i redovnosti placanja faktura.
Faktura u bazi (izmedju ostalog) ima svoj broj, datum kada je izdata i datum kada je placena. Here comes the worst: ponekad klijent moze da se buni oko svojih faktura i onda ide objasnjavanje i razjasnjavanje koje se u bazu belezi kao delay period. Svaki delay period ima begin date i end date i taj period ne ulazi u krajnji rezultat. Dakle, ako je firmi trebalo 7 dana da plati fakturu, a 3 dana je bio delay period, krajnji rezultat je 4 dana. Tih perioda moze da bude i vise za jednu fakturu i mogu da se preplicu (jedan moze da pocne pre nego se prethodni zavrsi). Ako je placena istog dana, broj dana je 1.

Primer 1: faktura je izdata prvog u mesecu. Od 3. do 7. je jedan delay period, od 5. do 10. je drugi i konacno je placena 15. u mesecu. Broj dana je 3 (od 1. do 3.) + 5 (od 10. do 15.) = 8.

Primer 2: faktura je izdata 1. u mesecu. Od 3. do 6. je jedan delay, od 9. do 12. je drugi. Broj dana: 3 (od 1. do 3.) + 3 (od 6. do 9.) + 3 (od 12. do 15.) = 9

Dakle, treba izracunati broj dana za svaku fakturu (od dana izdavanja do dana placanja), ne racunajuci delay. Potrebno je napisati optimalan SQL kod (T-SQL, mada moze i PL/SQL), tj. stored proceduru. Problem treba da se resi SQL-om jer faktura (i firmi) ima na hiljade i ne moze svaka da se obradjuje posebno van baze.

Ulaz:
(primer)

invoice_nbr......invoice_date.......date_paid.........delay_begin.....delay_end
----------------------------------------------------------------------------------
111111............10/01/2001........10/23/2001.......10/04/2001......10/12/2001
123456............11/01/2001........12/15/2001.......11/20/2001......11/30/2001
123456............11/01/2001........12/15/2001.......11/25/2001......12/05/2001
234567............12/01/2001........12/16/2001.............null................null.......
...

Izlaz:
invoice_nbr......days_to_pay
---------------------------------
111111.................15
123456.................30
234567.................16
...

Postojece resenje nije bas najbolje, pa me zanima da li neko ima bolju ideju (napr. bez kursora u T-SQLu). Hvala unapred.

A computer once beat me at chess, but it was no match for me at kick boxing.
 
Odgovor na temu

Mihailo
Mihailo Đorić

Član broj: 1016
Poruke: 2875
*.verat.net



+1 Profil

icon Re: Da li neko hoce da oproba zube na ovome?12.05.2002. u 15:13 - pre 243 meseci
Na prvu tabelu postaviš after insert trigger koji će da upisuje u drugu tablelu
kada se upiše nova faktura(zapis).

Na drugu postaviš instead of insert triger koji proverava da li taj broj fakture postoji u drugoj tabeli, ako postoji radiš update fakutre(zapisa), ako ne upisuješ nov row.


Create trigger fakture_na_ranglista on fakture
AFTER INSERT
AS
Begin
insert ranglista ...
end;

Create trigger rang_trig on rang
INSTEAD OF INSERT
AS
Begin
if ((select inovice_nbr from inserted) not in
(select inovice_nbr from ranglista))
insert ranglista ....
else
update ranglista ...
End;
Go

Valjda sam te dobro razumeo :)
 
Odgovor na temu

Last Man Standing
Misha Kostich
Chicago

Član broj: 3775
Poruke: 101
*.client.attbi.com



+1 Profil

icon Re: Da li neko hoce da oproba zube na ovome?12.05.2002. u 20:34 - pre 243 meseci
Ne, nisi. Nema trigera, imas samo prvu tabelu i treba da se napravi procedura koja ce od ulaznih podataka da napravi izlazni result set.
A computer once beat me at chess, but it was no match for me at kick boxing.
 
Odgovor na temu

Riste Pejov
Team Leader/Senior Software Developer @
Ein-Sof ltd Skopje
Skopje, Macedonia

Član broj: 128
Poruke: 571
*.on.net.mk.

Jabber: richie@bagra.net.mk
ICQ: 154236769
Sajt: riste.softver.org.mk


Profil

icon Re: Da li neko hoce da oproba zube na ovome?13.05.2002. u 04:04 - pre 243 meseci
samo mi nije jasno kako u tabelu imas samo jednog delay perioda,
a u primera 1 i 2 imao si po 2 delay perioda ?

jesu li delay periodu u posebnoj tabeli, ili ih ima po 2 za svake faktura u istoj tabeli ?

Ukoliko je broj delay perioda varijabilan(0-n), onda ne mozes izvesti ovo bez cursora,

People who think they know everything tend to irritate those of us who do.
 
Odgovor na temu

Mihailo
Mihailo Đorić

Član broj: 1016
Poruke: 2875
*.ppp-bg.sezampro.yu



+1 Profil

icon Re: Da li neko hoce da oproba zube na ovome?13.05.2002. u 13:25 - pre 243 meseci
Da li postoji primary key (unique), nisi naveo tu kolonu ?
 
Odgovor na temu

Riste Pejov
Team Leader/Senior Software Developer @
Ein-Sof ltd Skopje
Skopje, Macedonia

Član broj: 128
Poruke: 571
212.110.78.*

Jabber: richie@bagra.net.mk
ICQ: 154236769
Sajt: riste.softver.org.mk


Profil

icon Re: Da li neko hoce da oproba zube na ovome?14.05.2002. u 18:48 - pre 243 meseci
Citat:
Mihailo:
Da li postoji primary key (unique), nisi naveo tu kolonu ?

Iz aviona se vidi da je invoice_nbr=PK
People who think they know everything tend to irritate those of us who do.
 
Odgovor na temu

Mihailo
Mihailo Đorić

Član broj: 1016
Poruke: 2875
*.verat.net



+1 Profil

icon Re: Da li neko hoce da oproba zube na ovome?14.05.2002. u 20:59 - pre 243 meseci
Citat:
T-SQL HELP:
A primary key constraint ensures no duplicate values are entered in particular columns and that NULL values are not entered in those columns. You can use primary key constraints to enforce uniqueness as well as referential integrity.


Ne znam iz kog aviona gledaš :)

Citat:
Last Man Standing:
invoice_nbr......invoice_date.......date_paid.........delay_begin.....delay_end
----------------------------------------------------------------------------------
111111............10/01/2001........10/23/2001.......10/04/2001......10/12/2001
123456............11/01/2001........12/15/2001.......11/20/2001......11/30/2001
123456............11/01/2001........12/15/2001.......11/25/2001......12/05/2001
234567............12/01/2001........12/16/2001.............null................null.......
 
Odgovor na temu

Last Man Standing
Misha Kostich
Chicago

Član broj: 3775
Poruke: 101
*.client.attbi.com



+1 Profil

icon Re: Da li neko hoce da oproba zube na ovome?15.05.2002. u 02:28 - pre 243 meseci
Primary key je kombinacija invoice_number-a i delay_id-a (ta kolona ovde nije data), ali to ovde nije bitno. Tabela koja je data "malo" je denormalizovana i samo je medjurezutlat. Problem je kako na osnovu svih delay perioda (kojih moze biti do 4 - citaj N - za svaku fakturu) izvuci broj efektivnih dana potrebnih da se faktura plati. Neki delay periodi mogu da se preklapaju i onda te "zajednicke" dane ne treba racunati dva puta.
Primeri podataka koji su dati, samo su ilustracija mogucih kombinacija.
U svakom slucaju, hvala na trudu. Ako vam neka ideja padne na pamet, molim vas javite
A computer once beat me at chess, but it was no match for me at kick boxing.
 
Odgovor na temu

Ivan Tanasic
BGD-SRBIJA

Član broj: 220
Poruke: 965
*.yubc.net

Jabber: Autoexes@jabber.sk
ICQ: 129145438


Profil

icon Re: Da li neko hoce da oproba zube na ovome?15.05.2002. u 15:14 - pre 243 meseci
Nisam neki sql strucnjak, tj znam malo sql a malo sam zaboravio :D al to nije sada najbitnije, veci imam ideju kako bi se to teoretski resilo.

naime potrebno je da svaki od delay datuma pretvoris u redni broj dana od 1.1.1 (prvog prvog prve godine, ili ne mora, mozes recimo od 1.1.1900 il tako nesto, nije tolko vazno...

To uradis sa svim datumima, vidis koji je redni broj je najmanji, vidis koji redni broj je najveci, oduzmes ih i dobijes protekli broj dana. Ako ti bas nije jasno mogu da ti bacim neki pascal/java/c kod koji bi razjasnio stvari :)) (nadam se da nisam mnogo omano :))))
Ivan Tanasic - Autoexes

>cd pub
>more beer
 
Odgovor na temu

Riste Pejov
Team Leader/Senior Software Developer @
Ein-Sof ltd Skopje
Skopje, Macedonia

Član broj: 128
Poruke: 571
212.110.78.*

Jabber: richie@bagra.net.mk
ICQ: 154236769
Sajt: riste.softver.org.mk


Profil

icon Re: Da li neko hoce da oproba zube na ovome?15.05.2002. u 18:35 - pre 243 meseci
Citat:
Mihailo:
Ne znam iz kog aviona gledaš


Izgleda me nisi razumeo , video sam da ima duplikate, ali ta kolona bar mojom logikom mora biti u nekoj composite PK

nema veze, evo malo sam se potrudio i napisao osnovu za stored proc
samo jos treba da se ubace pravi tipovi.
Code:

DECLARE  @del_begin_1, @del_end_1, @del_begin_2, @del_end_2 -- ovo su valjda tipa date promenljive
DECLARE @del_period,@del_id_1,@del_id_2 --- ovo su int tipa promenljive

DECLARE my_cursor CURSOR FOR SELECT delay_id,delay_begin,delay_end FROM delay_table WHERE delay_id = '1234' ORDER ASC BY delay_begin
OPEN my_cursor 
FETCH NEXT FROM my_cursor INTO @del_id_1, @del_begin_1, @del_end_1
WHILE @@FETCH_STATUS = 0 
BEGIN 
@del_start = @del_begin_1
@del_kraj = @del_end_1
FETCH NEXT FROM my_cursor INTO @del_id_2, @del_begin_2, @del_end_2
IF DATEDIFF(d,del_end_1,del_begin_2)>0 THEN
@del_period = @del_period + DATEDIFF(d,@del_kraj,@del_start)
ELSE
@del_kraj = @del_end_2
ENDIF 
@del_id_1 = @del_id_2
@del_begin_1 = @del_begin_2
@del_end_1 = @del_end_2
END 
PRINT ' delay period :'[email protected]_period+' dana'
CLOSE my_cursor 
DEALLOCATE my_cursor


jos nesto ... nemam pri ruci MS SQL, tako da ne mogu probati kod, siguran da ima koju gresku, ali nadam se da ces je lako srediti
u kod delay_id je fiksan, samo treba input promenljiva

People who think they know everything tend to irritate those of us who do.
 
Odgovor na temu

[es] :: Baze podataka :: Da li neko hoce da oproba zube na ovome?

[ Pregleda: 4003 | Odgovora: 9 ] > FB > Twit

Postavi temu Odgovori

Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.