[ MarkoBalkan @ 22.07.2007. 12:26 ] @
situacija je slijedeca.
imamo server i 20-30 racunala u mrezi.sva racunala imaju staticke IP adrese.
na serveru je mysql baza.



ako se na svako racunalo stavi aplikacija i sa svakog pristupa serveru, dali ce to raditi nekakvom normalnom brzinom.jer aplikacija bi bila pisana u .netu sa koristenjem sql-a direktno u kodu, bez stornih procedura, bez dataset-a itd..
ja mislim da nijedna tablica ne bi imala vise od 300 000 - 500 000 redoava!
kad sam se spajao localhost, za nekakvih 200 000 redova je trebala 1 s da se prikaze u datagridview.

a sta da koristi 20 ljudi istovremeno, sa 20 racunala?
kojom bi to brzinom radilo?



[ roberto555 @ 22.07.2007. 20:51 ] @
radilo bi ok ak bi napravio dobro program, pod dobro ne mislim da to što si napravio nije dobro nego, zašto ti odjednom treba 200 000 slogova iz baze u datagridview-u? što radiš sa njima?
[ MarkoBalkan @ 23.07.2007. 08:07 ] @
mozda ne bi sve islo u datagridview, nego bi se nesto i filtriralo!
[ aleksandarpopov @ 23.07.2007. 08:58 ] @
Gledaj da na klijente u datasetove prevlacis samo onoliko podataka koliko korisniku stvarno i treba (tj. da izbegavas SELECT * FROM...) i ne bi trebao da imas vecih problema. A brzina zavisi od hardware -a takodje.
[ logic_rabbit @ 23.07.2007. 12:13 ] @
A sta ako coveku treba poziconiranje kroz grid tacno na odredjeni slog?
Zar onda ne bi trebao sve podatke prikazati u gridu?
[ jablan @ 23.07.2007. 12:33 ] @
Jedino ako je njihov broj do par desetina. U suprotnom: pretraga, incremental search i/ili filtriranje po parametrima.
[ bjevta @ 24.07.2007. 07:39 ] @
"jer aplikacija bi bila pisana u .netu sa koristenjem sql-a direktno u kodu, bez stornih procedura, bez dataset-a itd.."

ima više načina da se ubrza aplikacija koja radi na 20-30 računara u LAN-u:
1. ne činiti ništa, jer sa ovom brzinom mreža i sadašnjeg hardvera 30 računara jedva da je više od solo računara. svaki odziv računara u trajanju DO 2 SEC se smatra ok, osim ako nemaš nekog nervoznog baju kao user-a.

2. select koji vraća 200 000 slogova? pa, zamisli da ti neko da 2 tone knjiga da pročitaš do utorka - sama količina podataka je beskorisno ogromna. Sa stanovišta ljudske percepcije 5-7 podataka u jednom trenutku je optimum. Dakle, što reče Jablan, search, itd. Ovde je bitnije da obratiš pažnju na usability nego na performanse - dobar usability olakšava i posao oko performansi.

3. Stored procedure i view-ove radi baza na serveru i nema protoka kroz mrežu, osim rezultata upita. Dakle, preporučujem da napraviš par view-ova i procedura za najčešće korišćene search-eve.
[ negyxo @ 24.07.2007. 07:54 ] @
Vidim niko ne spominje kesiranje, pa evo ja da ga spomenem. Mozes a i trebalo bi da kesiras podatke, bar one koje se ne menjaju cesto, ovo su obicno sifrarnici jer oni se uglavnom unose jednom i retko se menjaju (prim. mesto, vrstaPosla, skola...).
[ PeraKojovic @ 25.07.2007. 12:23 ] @
Pozdrav,
Posto se pominje datagridview, problem u njemu moze da bude ucitavanje 200.000 slogova,
ali to je pre svega problem datagridview-a a ne SUBP-a.

Pera
[ vladdy @ 25.07.2007. 16:40 ] @
Potpuno je pogresno odjednom uzimati 200,000 podataka sa servera, zaista sumnjam da je tvoja aplikacija tip programa kojem to zaista treba.

Opet pitanje "sta ce jadni korisnik za x00,000 podataka, da poludi nacisto".

Ako ti trebaju bilo kakvi proracuni tj. calculated values to mozes da racunas i na serveru a uz pravilan filter se klientu da ono sto mu zaista treba.

Eh sada, ako mu stvarno trebaju ti podaci radi se paging ili neka vrsta "delayed loading-a" i nikada se ne vraca sve odjednom ali to je vec druga tema.



Citat:
negyxo: Vidim niko ne spominje kesiranje, pa evo ja da ga spomenem. Mozes a i trebalo bi da kesiras podatke, bar one koje se ne menjaju cesto, ovo su obicno sifrarnici jer oni se uglavnom unose jednom i retko se menjaju (prim. mesto, vrstaPosla, skola...).


Ovo je zanimljiv i dobar predlog ali zna da bude veoma komplikovan posto je potrebno imati caching mehanizam (business objects, ...) a onda dolazi i u pitanje tacnost podataka s obzirom da su kesirani na klientu. Naravno, sve je moguce uraditi pa i periodicni refresh podataka kao i eventualni callback kako bi podaci bili koliko-toliko sinhronizovani ali u multi-user okruzenju sa 20 ljudi istovremeno to moze da bude glavobolja.
[ MarkoBalkan @ 26.07.2007. 08:57 ] @
i sad jos jedno pitanje.
recimo netko updata neke podatke iz nekog reda ili ih koristi!
kako u MySql onemoguciti drugom korisniku pristup tom retku, moze ga vidjeti, ali ga ne moze mijenjati!
[ PeraKojovic @ 26.07.2007. 10:19 ] @
E pa prijatelju, locking je zadatak samog sistema BP...
A zato je vladdy i rekao da se radi paging, tj ucitavanje delova podataka,
a ne da ucitas 200.000 pa da mysql zakljuca svih 200.000 (ne radi
bas tako ali govorim prinicijalno).

Pera
[ MarkoBalkan @ 26.07.2007. 20:57 ] @
nisam ni spomenuo tih 300000.
nego ucita se jedan red, i sad se slucajno desi da taj red ucita i netko drugi na nekom drugom racunalo.
slucajno!

sad ovom drugom treba onemogucit mijenjanje.znaci treba zakljucati za ovog drugog.nikad nisam to radio pa pitam!
[ roberto555 @ 27.07.2007. 07:40 ] @
ja sam to napravio tako da sam kad sam išao raditi update, provjerio dal je ovaj na serveru isti kao i ovaj koji je promjenjen al prije izmjene, ako je znači da je u međuvremenu netko napravio promjene, onda sam otvorio novu formu gdje sam prikazao šta je različito pa da si odabere dal želi to presnimiti ili ostaviti tako kako je! <malo više tipkanja al radi odlično>
[ bjevta @ 27.07.2007. 10:54 ] @
za konkurentni rad koristi se optimistic locking, DataSet klasa već ima sve što treba - samo hvataš exception.

Međutim, najbolji način da se spreče problemi konkurentnog rada jeste da se razrade use case-ovi i podeli posao po operaterima. Do sada nisam video slučaj gde to nije moguće.

Uzgred, napiši u par rečenica kakva je to aplikacija: čemu služi i šta radi?
[ MarkoBalkan @ 27.07.2007. 12:58 ] @
standardna poslovna aplikacija koja sadrzi ponude,realizacije itd..
sad recimo netko ucita ponudu i recimo da se prihvati za realizaciju, sad se mogu dodavati podaci, mijenjati itd..