Citat:
Ipak kad bi postojalo opste pravilo onda bi to bilo:
1. Oformis stored proc koji ce vracati cursor/recordset
2. Unutar stored proc-a oformis cursor koji ce za svakog recorda dodati row number
3. Otvoris kursor/select * from storedproc sa klienta i prikazes podatke
Ako se ne varam ovde je rec o bazama podataka, a ne o nekoj konkretnoj
bazi. Tako da princip koji sam ja izlozio moze da se primeni svuda i
nasvakom mestu, bez obzira na vrstu baze. A to moze biti i Access ili
Paradox ili VisualFox ili bilo sta.
Nemaju svi sistemi mogucnost izvrsavanja i cuvanja uskladistenih
procedura, okidaca, kursora, recordseta i slicno.
Normalno, da ako sistem podrzava privremene tabele u memoriji
(kursore) da ih treba primeniti. Naravno da treba primeniti i sve
ostale ostale pogodnosti koje sistem pruza, ali princip ostaje isti.
Citat:
Recimo imamo tabelu sa 1mil recorda.
Kod SQL Server imas ovako:
1. Imas milion fetch operacija sa diska da uzmes tabelu
2. Jos milion da je insertujes u temp tbl
Podrazumeva se da se kolicina podataka koja se prikazuje ogranicava
(WHERE klauzula jos uvek postoji, a i radi na svim sistemima)
Citat:
3. jos milion i nesto da ih join-ujes
E ovo mi tek nije jasno. Zasto bih join-ovao kada je posao vec
zavrsen, oformljeni su redni brojevi slogova i prikazuju se?
Citat:
Na kraju ... za SQL Servera .. valjda ce ti biti najjeftinije da rownum presmetas kod klijenta ....
Ko jos salje klijentu nesto sto mu nije potrebno? Valjda je opste
pravilo da klijent, kroz mrezu, prima samo one podatke koji su mu
potrebni i vec pripremljeni za njegove potrebe. Znaci bez ikakvih
nepotrebnih i privremenih podataka.
Citat:
Znaci opet ... menjaj taj SQL Server sa pravom bazom :-D
Opet ponavljam ovo pitanje sam svahtio kao opste pitanje a ne vezano
za neki odredjeni sistem baze podataka.