Smještanje rezultata obrade podataka

Situacija je sljedeća:
imamo VB.Net desktop (form) aplikaciju koja se povezuje na SQL Server bazu.
Aplikacija prilikom pokretanja čita veću količinu podataka, radi odredjenu kalkulaciju nad tim podacima i prikazuje podatke zajedno sa rezultatima kalkulacije.
Ovo ima za posledicu da se aplikacija dosta sporije pokreće.

Rješenje je da se navedana kalkulacija premjesti u automatski task koji bi se pokretao svakih n sati/minuta na posebnom serveru i osvježavao brojke.
Na ovaj način bi klijentska aplikacija prilikom pokretanja samo pročitala ono što je već izračunato.

Sad je pitanje gdje smjestiti te rezultate računanja ( u periodu od završetka taska do startovanja klijentske aplikacije). Koje rješenje mislite da je bolje?

1. Dodati novu tabelu u bazi podataka koja će sadržati rezulate računanja (navedeni automatski task bi "osvježavao" tu tabelu).
Klijent aplikacija bi onda kod pokretanja samo procitala podatke iz te nove tabele.

2. Napraviti da automatski task rezultate računanja smješta u skup VB.NET objekata (umjesto u tabelu u bazi) koji bi bili dostupni preko LAN mreže (klijenstskoj
aplikaciji). Procjena je da bi navedeni VB.NET objekti trajno "držali" oko 80 MB RAM memorije na serveru gjde se task izvršava.

Nezgodno je reći a ne znati prirodu rezultata kalkulacije, odnosno prirodu cele aplikacije, kao ni vreme potrebno za izvršavanje kalkulacije.
Ako bi se kalkulacija izvršavala u određenim vremenskim intervalima, pretpostavljam da je moguće da u određenim momentima rezultati te kalkulacije nisu tačni, jer su se u međuvremenu pojavili novi podaci koji bi trebali da se ukalkulišu. Ako je ovo problem, bolje je uraditi refaktoring SQL koda i svesti ga na najkraće moguće vreme. Taj kod bi mogao da se izvršava asinhrono, tako da korisnik prilikom pokretanja aplikacije odmah na ekranu ima osnovne podatke, a rezultate kalkulacije da sačeka.
Ako ovo nije zadovoljavajuće rešenje, ostaju one ponuđene, dakle rezultati kalkulacije u tabeli ili u memoriji. Ako je server opterećen čestim upitima, bolje je rešenje sa rezultatima u memoriji, jer pretpostavljam da server ima dovoljno RAM-ada ga 80-100MB neće značajno opteretiti.

Nisam bas siguran sto se tice stabilnosti rjesenja sa .Net objektima.
Kao sto sam naveo, ti objekti biti trebali da budu stalno u radnoj memoriji servera,
da li ce .Net Garbage Collector (ili neki drugi proces) automatski obrisati te
objekte izvesno vrijeme nakon kreiranja?

Mislio sam da rezultat kalkulacije staviš u neki public static objekat.

Zbog čega bi komplikovao sa objektima na serveru http-om?

1. Ako se proces koji drži podatke završi, nestaju i podaci,
dakle imaš problem ako se radi o scheduled task-u ili
ako je to recimo ASP.net aplikacija koju može IIS da reciklira
ili restartuje.

2. Ako proces koji drži podatke ostaje živ i imaš referencu do njih
preko npr. statičke promenljive, neće ih GC brisati, ne brini.
Ne postoji nikakav drugi eksterni mehanizam koji bi uništio podatke
tvog procesa u memoriji, to radi isključivo GC i po strogim pravilima,
dakle ne brini.

Ja bih sve to držao u bazi i ne bih petljao sa http serverom.

U pitanju je desktop a ne web aplikacija

Govorim o ovome - može da bude i windows servis, WCF servis, može da bude desktop aplikacija, može da bude asp.net aplikacija...
Zavisno od toga šta je naumio može/ne mora da ima problema.

Moram priznati da i ja naginjem ka rjesenju sa dodatnom tabelom u bazi.
Moje shvatanje je da VB.NET objekti (bilo da je web ili desktop aplikacija) treba da postoje onoliko koliko traje sesija,
a u ovom slucaju bi se nastavilo sa cuvanjem objekata u memoriji servera i nakon zavrsetka sesije na klijentskoj strani

Znatiželjan sam - ako nije tajna, kakva je to kalkulacija čiji je rezultat 80MB?
Kako prikazuješ rezultat, jel to za neki dijagram ili šta?

Kalkulacija je malo slozenije racunanje nekoliko procentualnih vrijednosti za
svaki procitani slog iz baze (a ima ih dosta), na osnovu odredjenih numerickih i datumskih
vrijednosti u tom slogu i slogovima pomocnih tabela.
Kao sto sam vec napisao, ja naginjem ka tome da se te vrijednosti cuvaju i osvjezavaju
u novoj database tabeli (osvezavanje bi vrsio scheduled task samo za slogove gdje je bilo izmjena u zadnjih n minuta).
Medjutim tu je i taj drugi prijedlog da se i pocetni podaci i rezultati
obrade smjeste i osvjezavaju u .NET objektima posebnog servera (mislim da bi bio u pitanju Windows servis).
Posle bi klijentska aplikacija u stvari preko LAN mreze koristila te objekte kao izvor podataka
(umjesto konekcije na bazu) i prikazivala izvjestaj u obliku dijagrama i datagridview-a uz mogucnost exporta u Excel.

Sa pozicije izmene koda, tj. složenosti implementacije, jednostavnije je da se rezultat čuva u bazi.
Program za računanje već imaš, samo treba njegov rezultat učiniti perzistentnim.

Možda je bolje rešenje da se koristi materijalizovani pogled nego tabela (mislim da se to drugačije zove u SQL Server okruženju).

OK, ovde (https://en.wikipedia.org/wiki/Materialized_view) kaže da se to zove indexed view, ali nisam siguran da je to isto kao Oracle materialized view.

Ako imaš samo dekstop aplikaciju i SQL server onda nemj komplikovati sa posebnim serverok, aplikacijom i slicno.

Prsoto napravi da se u tvojoj palikaciji povremeno, u zasebnoj niti pokrece proces koji ce da radi taj preracun. Logično je da se taj preračun upisuje u neku tabelu ako ti trebaju povremeno samo delvio te tabele. Ako ti stalno trebaju svi slogovi onda je bolje da preracun cuvas u nekom objektu, jer ces ga, i tako svaki put praviti,a ustedeces znatno jer nece ssvaki put praviti konekcuju na pbazu i izvlacenje podataka iz nje.

Već su ti skrenuli pažnju da je problem povremenog preracuna sto ce ti podaci biti povremeno i zastareli.

Ako je to zastarevanje problem, onda mislim da ti ne gine da imas redundansu, odnosno da svaki put kada u bazu upisujes neki podatak koji utice na preracun, uradis i preracun, naravno ne svih podataka nego smo onih na koje j epromena uticala i da to smestas u zasebnu tabelu (ili objekat). Tako ces preracun uvek imati azuran. Ako preracunate podatke cuvas u tabeli, ovaj preracun mozes napraviti nekim trigerom na nivou baze tako da tvoja apliakcija time i ne mora da se bavi.

Potpis

http://pedja.supurovic.net - http://wireless.uzice.net - Besplatni .RS domeni - Mikrotik uputstva - YT9TP - OpenStreetMap Srbija