[ djvlajko @ 03.10.2017. 15:32 ] @
Program je napisam u Vb6 i Sql 2008 R2.

Jedan njegov deo azurira tabelu stranaka cija je struktura

Stranke
-------
stranka_jmbg - nvarchar(13)
datum_prijema - date
redni_broj - smallint

Svakog dana, ispocetka, stranke se primaju i pocinju od rednog broja 1 i svaka sledeca dobija broj uvecan za 1.

Problem je u tome sto se neke stranke vrate i zele da odustanu. One se brisu i njihovo mesto je upraznjeno.
Prazna mesta je potrebno popuniti sa novopridoslom strankom.

Da bi resio problem, uveo sam pomocnu tabelu Brojevi :

Brojevi
-------
Broj - smallint

Tabela ima 1000 slogova sa vrednostima od 1 - 1000.

Upitom :

Code:


select min(Broj) as SledeciBroj from Brojevi left join (select Redni_broj as BrojUzorka from Stranke where Datum_prijema = '" & TekuciDan & "' Tmp on Tmp.BrojUzorka = Brojevi.Broj where Tmp.BrojUzorka IS NULL



gde je TekuciDan = tekuci radni dan - datum.

Ovo mi daje sledeci slobodan broj uzimajuci u obzir i praznine nastale brisanjem, ali mi se cini da je malo "grubo" ...

Kako bi se ovo moglo napisati, a da bude sto brze za izvodjenje.

Hvala ...


[ dusans @ 03.10.2017. 16:36 ] @
Code (sql):

SELECT ISNULL(MIN(Redni_broj), 0) + 1 AS Sledeci FROM Stranke
WHERE (Redni_broj + 1) NOT IN (SELECT RB.Redni_broj FROM Stranke AS RB)
 

[ jablan @ 03.10.2017. 16:39 ] @
Taj način je ok. Ono što nije OK je način kako interpolišeš TekuciDan u svoj query. Takođe, ceo koncept ponovnog korišćenja brojeva je sumnjiv, nadam se da imaš jak razlog zašto to radiš.
[ djvlajko @ 03.10.2017. 17:57 ] @
Da, bilo bi lepo kada ne bih morao da koristim praznine ali moram,

dusans, kako ce se ponasati NOT IN ako u tabeli stranke postoji 500.000 - 5.000.000 slogova sto je realno za ocekivati. Znam da sam u nekim situacijama uocio prinetno usporenje kada sam koristio tu
instrukciju ...
[ mmix @ 03.10.2017. 18:48 ] @
Vodi samo racuna ako je multi-user sistem, lako moze da se desi da dve transakcije povuku isti slobodni broj, u tom slucaju moras da provuces sve ovo kroz neku exclusive lock transakciju.
[ jablan @ 04.10.2017. 08:51 ] @
@djvlajko: ja bih lično pre išao na tvoje rešenje nego na @dusans-ovo, naravno pod uslovom da si siguran da nikad nećeš imati više od 1000 ili koliko već brojeva.
[ dusans @ 04.10.2017. 09:28 ] @
Vlajko, nisam shvatio da se u stvari bojiš problema sa performansama,
već sam mislio da si iz nezanja iskomplikovao rešenje sa dodatnom tabelom,
pa sam ti predložio trik sa R + 1 bez detaljisanja oko filtera po datumu, itd.

Umesto NOT IN možeš da probaš i drugu varijantu:
Stranke filetrovane po datumu left join na isto to preko R = R + 1
gde je join-vani rekord null.
Index nad datumom i rednim brojem kakvo god rešenje da praviš.

Rešenje sa dodatnom tabelom kakvo si dao obično bude performantnije.
[ djvlajko @ 04.10.2017. 15:35 ] @
Mislim da je i to predimenzionisan broj (600). Rec je o broju stranaka koje salter moze da primi za 8 sati rada ...

Ipak cu se ja drzati opcije sa pomocnom tabelom. Bitna mi je brzina, a kako @dusans kaze, bolje su performanse (u tom slucaju).

Hvala na savetima i pomoci