Data set vs List

Kada povratim podatke iz baze da li je bolje da podatke drzim u nekoj listi ( List<Customer> npr)? Jer ja uvek to tako radim i sve radnje ovako obavljam (+ enterprise library naravno). Sada me zanima da li ima potrebe nekad koristiti DataSet? Taj objekat nikada nisam koristio jer sam prvi put cuo da je on kao los za performanse i od tada ga nisam pipnuo, sada mi je bezveze to palo na pamet pa me zanima kako drugi gledaju na ovo.

PozZ

Mozda ti ovo da ideju za sta se koristi disconnected database architecture - dataset.

http://www.startvbdotnet.com/ado/default.aspx

http://www.informit.com/articles/article.aspx?p=27151

Zavisi šta radiš ... ADO.NET sa DataSet-ovima i DataBinding-om je odličan za manje jednostavne projekte.

Da li je DataSet loš za performanse? Opet zavisi kakve performanse želiš. Svaka tehnika programiranja se može pogrešno upotrijebiti, te tako napraviti beskorisnom. Sve u svemu, više je ispravno reći da nije loš po performanse, nego što jeste.

---

Postoji nekoliko razloga za upotrebu Dataset-a:

1. Disconected operations koje ti je zevs85 naveo, s tim sto naravno i List<T> moze da se napravi da podrzava to ali uz dodatni kod.
2. Jednostavnija upotreba (GUI dizajn), sto ajd da kazemo nije presudno
3. Omogucava multi-object strukturu sto ne mozes direktno postici sa List<T> (Dictionary<string, List<T>> ? )
4. Omogucava uspostavljanje i odrzavanje relacionog modela izmedju objekata
5. Omogucava uspostavljanje validacije i default vrednosti
6. Omogucava serijalizaciju kompletne strukture zajedno sa semom, ukljucujuci i relacije (nested ili linked po zelji)
7. Omogucava merge dve liste objekata

Nista od ovoga nije nemoguce izvesti manuelnim kodiranjem tih funkcionalnosti ali ako implementiras sve to u T, List<T> i Dictionary<string, List<T>> onda si u osnovi dobio typed DataRow, DataTable i DataSet objekte

Ta prica za performanse je malo naduvana i najvise potice u stvari od netipiziranih datasetova. Kad pogledas operacije ucitavanja strukture i pristupa podacima imas ove korake:

1. Ucitavanje podataka u native sql strukturu, apsolutno identicno za sve, dal si radio preko DAABa ili je DataAdapter pozvao sqlcommand u osnovi je identicno, dobija se niz sqlDataRow
2. Schema discovery O(1): ovde je netipizirani dataset najveci trosadzija, mora da izanalizira strukturu koju ucitava (ispipavanjem columns prvog elementa ucitanog niza iz 1.) i da na osnovu toga dinamicki generise DataTable i njegov Columns. Tipizirani DataSet ovo nema kao sto nema ni List<T>
3. Generisanje instanci O(n): Ovde zapravo List<T> postize prvi gain. Ti direktno generises instancu T objekta dok tipizirani i netipizirani dataset moraju da koriste mapping tabelu. Ovde je realno (bar po meni) doslo do propusta u ado.net timu, ne postoji ni jedan valjani razlog da se tipizirani DataAdapter oslanja na netipizirani Fill, sve informacije su vec prisutne design time i generisani kod moze komotno da napravi Fill override gde je instanciranje identicno kao za List<T>, al ajde.
4. Ubacivanje instanci u listu O(n) + merge O(n^2): ova operacija/e je skupa u Datasetu ali sa razlogom, ovo je trenutak u kom se proverava i kontrolise relacioni model i dataset nece dozvoliti da se doda instanca koja krsi model. List<T>.add je brzi samo i iskljucivo iz razloga sto nema relacioni model koji treba da ispostuje. Ovde bar nisu toliko zakazali sa performansama jer se sve relacije definisu column objektima umesto imenima polja sto smanjuje penalty koji izaziva citanje netipiziranih datasetova.

Na tu temu, u datasetu pristupanje redu i polju se obavlja kroz instancu DataRow obekta i ovde se desava onaj veliki pad performansi kojim se plase ljudi , svaki pristup bilo kom polju netipiziranog DataRow objekta je pretrazivanje columns strukture po stringu i onda lociranje celije po indeksu pronadjene kolone, ako se ne varam ovo je samo po sebi O(n^2) operacija zbog poredjenja stringova, pa se to onda dodatno komplikuje operacijom koju hoces da uradis. Tipizirani dataset nema tih problema jer su sva polja implementirana kao properties nasledjene klase pa je "trosak" pristupa isti kao za T.

Zakljucak, nemoj koristiti netipizirane DataSetove ako ti je performansa problem, ako ti treba nesto sa pocetne liste funkcionalnosti daj sebi oduska i koristi tipizirani dataset jer ces implementacijom tih funckionalnosti ionako izgubiti prednost koju ti daje List<T>. Ako ti ne treba nista od toga onda koristi List<T> ili jos bolje predji na Linq2Sql, DAAB je tu vise istorijska gradja ne verujem da to iko vise odrzava od kad je izasao Linq2Sql (btw, Linq2Objects funkcionise odlicno i nad datasetom za offline operacije ako ti trebaju, isto kao i za List<T>)

Realno ako pises program za dobrilu koja ce da ucita par redova to da mulja deset minuta i onda da uradi update tebi performanse nisu problem, sigurno imas neke poslovne procese i pravila u kojima bi ti dataset operacije pomogle i ti se sad vijas oko toga tako sto manuelno implementiras te operacija kao operacije nad List<T>. Sa tvog stanovista to je odlicno jer pravdas svoje radno mesto boljim performansama (sto je opet diskutabilno jer te operacije koje dodas kostaju kao i operacije dataseta), ali sa poslovne tacke gledista znaci da produzavas vreme razvoja aplikacije bez opipljivih ili bolje receno dovoljno znacajnih dobitaka u aplikaciji.

---

Hvala na opsirnom odgovoru :). Pitam zbog performansi jer sam napravio jednu aplikaicju koja iz baze ucitava oko 3.000 user-a. Sada svaki user ima svoju gomilu podataka slike itd. I ti svi podaci treba da se ucitaju nakon sto se aplikacija pokrene (klijent tako trazio) problem je bio taj da kada sam koristio DataSet da pokupim podatke aplikacija se startovala oko 3 minuta dok je kada sam logiku sa data set-om zamenio sa Listama dobio mnogo brze ucitavanje podataka. Ne znam da li sam ja nesto promasio :(

Hm, ni u apsolutnom ludilu i sa svim performance kaznama netipiziranog dataseta nema sanse da se 3000 redova ucitava 3 minuta zbog samog dataseta. Nesto drugo je tebi problem.

---

Ne znam, znam samo da mi je stariji kolega rekao da je sporo zbog data set-a jer se sve ucitava direktno u memoriju (slike itd), tada sam zamenio data set listom i ide mnogo brze, mislim normalna aplikacija. I zbog toga jer vecina iskusnijih od mene obicno kazu data set u .NET-u treba izbegavati jer su spori :(

Pa i sa List<T> sve ide u memoriju

Nezahvalno je komentarisati zasto je tvoj kod bio toliko sporiji u dataset varijanti, za te stvari sluzi profiler, ali 3 minuta aktivnog rada sa bazom je mnogo mnogo vremena za 3000 redova bilo cega narocito ako se radi samo ucitavanje. Mozda si problem resio nenamerno i slucajno kad si presao na List<T> jer te je tehnologija primorala da drugacije odradis posao, ali sam 100% ubejden da je problem mogao biti resen na nivou tipiziranih datasetova uz priblizno identicne performanske kao List<T> pristup. Pitanje na koje naravno isto ne znamo odgovor je da li su tebi zaista i bili potrebni datasetovi od samog pocetka (tj dal ti je trebalo nesto sa onog spiska koji sam ti dao).

---

A da li je kojim slucajem. Moglo da dodje to takvog usporenja ako sam isao preko Visual Studio Data Wizard-a posto jesam prvi put isao preko toga (bilo mi brze) :) ?

Evo jednog glasa za List posmatrano iz jednog ugla koji cini mi se niko nije pomenuo, a doduse nije vezan za performanse same aplikaicje. Naime, ako imate poveci projekat koji sadrzi recimo 100 tabela i mnostvo relacija, a taj projekat drzite recimo na svn-u(mada je sve jedno koji source control) moze da se desi da gubite puno vremena na razresavanje konflikta. Mala promena na dataset-u rezultuje mnostvom promena u mnogim automatski generisanim fajlovima "spod haube".

Takodje, dupli klik na xsd sa malo vise objekata slogira masinu (core 2 duo 2.2 Ghz sa 3 giga rama) na duzi vremenski period.

^
Koliko vise ?
Evo izmerih sada na Athlonu 2.2GHZ sa 3 giga RAM na source safe-u sa 20 objekata = ~5 sec.
Zatvorim , pa otvorim = ~ 1 sec.


Pa zar to nije valjda i poenta ?
Da ne bi posle menjao desetine linija koda manuelno ..

---

Ih bre, natera me da uzmem stopericu u ruke :). Rezultat: 1 minut i 18 sekundi ali ne znam kako da vidim koliko tacno objekata ima ali ima sigurno 100. Svaki sledeci pu mu treba oko 18 sekundi. Takodje, usisa oko 50 MB RAM-a pa i prilikom zatvaranja luduje po nekoliko sekundi. I jos jedna stvar, ne postoji nikakav search tako da odlazi puno vremena na trazenje jedne tabele.



Ne kazem ja da je to lose, samo kazem da ako je u medjuvremenu jos neko promenio nesto na datasetu i commitovao (check in) dobices conflict koji nije lako razresiti. Najcesce moras raditi ponovo sve

Ih bre, 100 objekata u jedan xsd :) Sad mi je jasno :D
Resenje za ovo je vise xsd-a fajlova sa manjim brojem tabela tj. objekata ..

No, kako god, xsd jeste glomazan i guta dosta memorije ,
ali mi je u jednom projektu gde sam imao 10 tabela od kojih svaka je imala po 20-30 polja spasao zivce i ustedeo mnogo vremena.
Upucao bih se da sam sve query-ije morao kucati na ruke ...

Po meni glavni nedostatak xsd-a je sto nema automatiku koda za transakcije ..


Ne znam sta koristis za source -version kontrolu,
ali kod Visual Source safe-a imas opciju Get latest version na svaki fajl ili projekat
i odmah dobijes sve izmene .

I pored ovog sigurno treba izmeniti nesto u kodu ,
(promenio si tip polja, dodao novo polje u tabelu itd...)
ali ruku na srce isto bi te to cekalo i bez xsd-a










_{[Ovu poruku je menjao deerbeer dana 21.12.2009. u 13:17 GMT+1]}

---

Mozda bi u DataSet vs. List moglo da se doda i vs. Linq2Sql :)
Ja sam najvise radio sa ovim poslednjim pa ne bih mogao napraviti neko adekvatno poredjenje ali bi me zanimalo cuti misljenja onih koji su upuceniji u vise tehnologija.

---

Mmix je jos ranije rekao da dataset nije sporan za male projekte ali ja pricam o ozbiljnom, velikom projektu gde se itekako vide nedostaci. Imamo mi ovde vise xsd-ova, tacnije 7 ali ovaj jeste najveci i cini jednu logicku celinu tako da se ne moze deliti na manje delove.



Nije bitno koji source control svi oni manje vise imaju iste opcije. Source safe ima get latest, a svn koji koristim ima update. Problem je to sto te to nece spasti ako ti i kolega u isto vreme menjate xsd. Onaj koji prvi commituje (check in-uje) onaj drugi moze samo da se hvata za struju kada bude uradio update ili ako pokusa direk' da commituje. Dobice toliko konflikata da ce u vecini slucajeva morati sve ponovo da radi.

Takodje, prica o automatskom generisanju sql naredbi, sve je to super ali iz mog iskustva cim naidje iole ozbiljiji projekat nema od toga nista vec mora sve rucno. Jos ako se u pricu ukljuci vise od jednog sistema za upravljanje bazom podataka onda od automatike nema nista

Linq2Sql je napustena tehnologija, tako da ne vredi sada ulagati trud u njega....

http://blogs.msdn.com/adonet/a...-linq-to-entities-roadmap.aspx

Ne treba nikad forsirati nesto po svaku cenu ako se unapred zna kakav ce biti projekat i njegov razvoj
Meni ne bi palo napamet ni u ludilu da strpam 100 objekata u xsd ..

Ali kad su u pitanju tako veliki projekti obicno se nasledi vise od 50-80 % postojeceg koda ,
koje po pravilu ne smes tek tako da bacis u djubre i napises ispocetka.

Ipak sto se tice xsd-a pravilo je jasno :
Sve je to u sustini izgleda odlicno , ali penal dodje kad-tad ..
Negde cenu toga moras da platis ..
Savrsenstvo ne postoji ..

---

Ali cak i kada bih sutra prestao da ga koristim, zanimao bi me odgovor na pitanje koje sam postavio :)

Inace, L2S sam poceo koristiti kada se EF jos nije pojavio (osim mozda u nekoj beta varijanti). Kada se pojavio, nisam bas jurio da odmah pokupim najnoviju stvar i radim sa njom u produkciji. Kasnije su projekti vec bili poodmakli a Linq2Sql je zadovoljavao potrebe i nije bilo opravdano trositi vreme na prelazak na EF samo zato sto je noviji.
Sad, sa novijim projektima, naravno da cu poceti postepeno da prelazim, ako nista drugo jer EF ima vise mogucnosti (a jedna od najbitnijih je nevezanost za MS SQL Server).

---

Polako, nemoj da zuris nigde . Linq2SQL ne ide nigde, to sto oni preporucuju EF ne znaci da su ostali metodi ugaseni i izbaceni i napusteni, po tom rezonu bi i datasetovi bili mrtvi. Videcemo sta su od propusta u prvom EFu ispravili u .NET4 ali ja za sada ne prelazim, cak i kad mi treba ORM eksterni alati kao llblgen daleko prevazilaze njegove mogucnosti i funkcionalnosti sa sve apstrakcijom. Ako ti L2S resava poblem i projekat je orijentisan na SQL nema potrebe da se zadubljujes u vecu apstrakciju.

Jedino sto se menja koncepcijski u razvoju L2Sa je da se Linq2SQL nece dalje razvijati sto ne znaci nista lose jer je Linq2SQL vec stable mature proizvod, ako mislite da bi ga trebalo dalje razvijati onda morate da kazete sta bi zapravo vi dodali u njega? Samo zato sto se ne prosiruje ne znaci da je umro.



Ja to nisam rekao, rekord sa kojim sam ja radio je 120 datasetova na bazi sa 260 tabela od kojih smo mi koristili nekih 50-ak sto sasvim sigurno nije mali projekat; sta vise i ja delim misljenje da je dataset sa 100 tabela preteran. Koliko use-case scenarija imas nad tim datasetom koji ukljucuje prisustvo podataka u svih 100 tabela? Ne bih se mogao zakleti ali bih se mogao opkladiti na odgovor "nijedan". Pre ce biti da je u neko doba linijom manjeg otpora baza preslikana 1-1 na dataset i da se to sad odrzava manuelno in-sync sa promenama na bazi sto jeste nocna mora. Po nekom mom shvatanju koje vidim da je primenjeno na dosta mesta datasetovi se organizuju po use-case scenarijima i taj pristup funkcionise veoma lepo, ako to znaci 30 datasetova sa po pet, sest tabela to je bolje nego jednog dataseta sa 100 tabela, najkompleksniji usecase koji sam imao a da nije mogao da se particionise imao je citavih 10 tabela i to je po mom ukusu bilo previse (to meni odmah zasmrdi na gresku u projektovanju baze). Ljudi izbegavaju taj multi-dataset pristup jer ce isti podaci u jednom trenutku biti ucitani u vise instanci razlicitih datasetova i misle da ce single-xsd singleton dataset resiti problem konkurencije (sto je zapravo cesce suprotno od istine); za dobro organizavanu aplikaciju to ne sme da predstavlja problem jer prosirenjem scope-a ti isti podaci se nalaze ucitani u drugim instancama programa na drugim masinama, resenjem te konkurentnosti resavas i internu konkurentnost u jednoj aplikaciji i nema potrebe za singletonima.



Za ovo prvo odgovor je vec dat, vise datasetova podeljenih po use-case principu znaci da se ti i kolega necete sudarati za isti xsd ako ne radite isti use case.

Automatika funkcionise sasvim lepo, problem je opet u koncepciji i "zlo"upotrebi datasetova kao db mehanizma. A ovo ide ruku pod ruku sa mitom u programiranju u .NETu da su datasetovi losi zato sto te promene na bazi teraju da promenis SVE datasetove gde se tabela pojavljuje zajedno sa svim adapterskim komandama i da je zbog toga L2S i List<T> pristup superiorniji. To je svojevrstan mit rodjen iz lenjosti i oslanjanja na apstrakciju a "dokazan" kroz argumentum ad ignorantiam. Cinjenica je medjutim da ovo nije uopste tacno ako se datasetovi koriste u use-case varijanti i bez "select * .." u adapterima. Ako imas jedan dataset sa 100 tabela, ili su naprimer svi adapteri puni CRUD adapteri koji ucitavaju, insertuju, modifikuju i brisu sva polja, pa naravno da ces morati sve da menjas i da je to sizifovski posao.

L2S i List<T> izgleda superiorniji samo zato sto radi sa minimalnim setovima neophodnih polja. Tabela u datasetu NE MORA da bude preslikana tabela iz baze, ako istu filozofiju iz L2Sa primenis sa razvojem datasetova i ucitavas taman onoliko polja koliko ti treba za use-case (dakle select polje1, pojle13 umesto select *) i ne pravis pun CRUD adapter ako ti ne treba onda apsolutno nemas nikakve potrebe da menjas ni tabele ni adaptere u svim datasetovima vec samo u onim koji se ticu tvog use-case-a a zbog cega si bazu i menjao. Za promene koje su kompleksnije u prirodi (npr obrisano polje ili dodato not null polje bez defaulta) i ne znas ciji si adapter sjebao prvi sledeci ciklus code testinga ce uhvatiti gresku u BLu i ispravka ce se retrofitovati uz saradnju sa projektantim; mada se takve promene daju preduprediti centralizovnim razvojem baze i malim dokumentacionim trudom i obicno ne bi trebalo programeri da budu ti koji iniciraju promenu te vrste. Tako da prica o "dataset nije za velike projekte" ne stoji, postoje samo "zloupotrebe" apstrakcije koju ta tehnologija donosi.



Sto se tice L2S, Perf(L2S) = Perf(List<T>) u principu se i radi interno kao List<T> i punjenje iz recordseta je identicno, jedino sto se razlikuje je kompilacija SQL komande iz IQueryable definicije naspram hardcoded stringa kojim ucitavas podatke za List<T> ali je to O(1) operacija u oba slucaja pa se ne smatra nekim problemom.

---

Ma, ne napustam ja L2S, ali treba na nekim projektima preci (tamo gde nije narocito bitno koji ce od njih biti) i steci nesto iskustva.


Pa, evo, sad u trenutku mi pada na pamet da bi mogao da se doda neki mehanizam da se uradi update nakon promene u bazi, umesto da brisem tabele i dodajem ih ponovo. Takodje, da postoji direktna podrska za many to many relacije.

---