MSSQL Compact Edition veličina i kapacitet

1. Da li je problem za MSSQL CE bazu da sadrži tabelu sa 20-tak hiljada redova (tabela sadrži informacije o članovima neke organizacije, 7-8 atributa svaki) ? Pretpostavljam da nije, ali bolje je da pitam jer nisam siguran.

2. Koliki bi OD PRILIKE mogao da bude fajl te baze sa jednom tabelom od 20-tak hiljada redova? Ako se ne varam ova verzija MSSQL-a sve drži u jednom .sdf fajlu, a pošto bih trebao da radim backup volio bih da znam kolika će veličina od prilike biti.

---

1. Nije nikakav problem da SQL Server Compact Edition baza sadrži i mnogo više od toga. Limit za veličinu baze je 4 GB.

2. Sve zavisi. Footprint baze je vrlo mali (20-tak KB), a ostalo zavisi od tipova podataka kolona i veličine samih zapisa. Ne možeš znati drugačije osim da simuliraš i probaš, jer će ti to neko drugi teško odgovoriti.

Za detalje - možeš posjetiti sljedeću adresu: http://www.microsoft.com/sqlserver/2008/en/us/compact.aspx

Hvala na odgovoru. Vjerovatno ostaje na tome da simuliram unošenje tih 20k redova, pa da vidim

---

Da ne otvaram novu temu, mislim da može ovdje. Treba mi predlog u vezi backup-ovanja baze (riječ je o Compact Edition bazi koju sam pominjao gore)

Moja aplikacija treba da radi na dva nepovezana računara. Na oba će se vršiti unos podataka u bazu, pa mi treba način da prebacujem bazu sa jednog na drugi. To se neće dešavati tako često, ali je neophodno. Ja sam planirao da aplikacija bazu backup-uje jednostavno preko DOS comande copy, tako da dobijem jos jedan .sdf fajl koji se poslije prebacuje na drugi kompjuter. Na drugom kompjuteru uzmem sve redove iz te baze i redom pomoću IF NOT EXISTS ubacujem one koji već nisu na lokalnoj bazi. Da li je ovo dobar način da se baza prenese sa jednog kompjutera na drugi? Ponavljam, nisam u mogućnosti da podignem server na koji će se kačiti oba kompjutera i dijeliti istu bazu.

---

To se zove Swivel Chair Integration i naravno moze da se namesti da radi, uz duznu paznju prema kljucevima.

Medjutim, ono sto meni nije jasno je kako nemas uslova za SQL express? Ok, nemas treci komp za dedicated server, ali jedna od dve postojece masine moze da nosi SQL Express i da se oba kompa kace na njega a Express mozes da instaliras i na XP Home edition i besplatan je. SQL CE je za single user i embedded aplikacije, eventualno za asp.net gde je shared hosting bez SQL-a i ne moze se instalirati nista, za sve ostalo ide express i jace.

---

Stvar je u tome što je jedan računar desktop, a drugi laptop. Na oba mi treba pristup bazi, a pogotovo na laptopu koji naravno neće uvijek biti u istoj prostoriji u kojoj je desktop. Pokušaću problem da riješim preko Swivel Chair Integration-a, ako ne uspijem onda ću tražiti neku alternativu. Hvala na odgovoru

---

Ne bih bio toliko kategoričan. Express verzija, naravno, otvara mnogo širi spektar mogućnosti (i sa korisničkog i sa programerskog aspekta - da ne ulazimo u detalje) - ali s' druge strane ne treba potcjenjivati Compact Edition bazu koja PODRŽAVA i višestruke konekcije i konkurentan rad.
Ako situaciju želiš MAKSIMALNO da pojednostaviš (od deployment-a do održavanja baze) - ne odbacuj Compact Edition u startu, već probaj da kreiraš prototipove i odluči sam.

Express edicija SQL Servera na klijentima otvara i nove probleme... nije džabe kreirana Compact verzija baze - samo je pitanje koja baza je najpodesnija za tvoje okruženje.

Pa moguce, tvoja kritika je mozda na mestu i ja mozda jesam malo subjektivan, ali ja jednostavno ne vidim neki veliki dobitak od CE-a na desktopu u LAN multi-user scenariju, suvise je mrsav za moj ukus . Jedini razlog zasto postoji u taj varijanti nije neki mnogo znacajan kao sto MS marketing tvrdi, zapravo svrha mu je da posluzi kao zamena za penzionisani Jet i time zaokruzi SQL Server kao all-rounder-a za data storage da bi sledeci korak bio svodjenje Access-a na GUI za SQLCE bazu, samim tim feature set CE-a mora biti >= onom od Jet-a pa je i kakav takav multi user bio neophodan.
Nemam ja nista protiv CE-a, ima on svoje namene, ali mislim da je cela ta prica sa multi-user iskustvom mnogo naduvana u marketinske svrhe; samim tim sto nema centralnog kontrolera baze nema ni centralne lokacije za memorijsko kesiranje stranica i kriticnih podsistema kao sto je locking engine, pa isto kao Jet i SQLCE u multi-user rezimu mora da odrzava locking tabele u file strukturi sa serijalizovanim pristupom, i kako god da spinuju tu cinjenicu to ne moze da bude skalabilno u nekoj SOHO varijanti sa rastucim brojem korisnika (da nije tako niko nikad ne bi morao da kupuje SQL server jer bi access uvek zavrsavao posao). A na kraju kad se baza zagusi resenje ne postoji jer nema direktne upgrade putanje iz sdf u mdf, sto je btw po meni totalna glupost, ako su vec trosili vreme da konsoliduju servise bar su mogli sve da svedu na jedan format. Fali njima jos par tehnickih resenja, a sumnjam da ce trositi vreme i trud na to kad postoji Express verzija za to.

---

pa naravno da nema centralnog kontrolera baze - SQL Server CE je embedded baza, i takva joj je i namjena. Pokreće se in-process, pri tome ne trošeći više od 2 MB memorije.

Naravno - da je mršav u poređenju sa ostalim verzijama SQL Servera - jest', ali takav je i koncept i u tome je suština. Ne slažem se sa tobom oko usporedbi (da će Access biti GUI za sljedeću SQL CE bazu i da se vrši penzionisanje JET engine-a), jer Access ima svoje tržište i namjenu, a SQL CE - svoje i sasvim drugačiju namjenu. Pomisli samo - ima li logike da Access MDB preraste u SQL CE SDF gdje bi se migrirali svi oni prateći objekti kao što su forme, izvještaji, makroi, raznorazne gluposti...

A SQL CE je čist - nema čak ni podršku za uskladištene procedure (što je, po meni, njegova najveća falinka).

Ipak, već sada - upotreba SQL Server-a Compact Edition-a donosi neke benefite (u odnosu na Access) sa aspekta programera, ali i korisnika. Recimo: podržan je LINQ/LINQ to SQL, takođe postoji i inicijalna podrška za sinhronizaciju, utaban put za podršku Microsoft Synchronization servisa, a da ne govorim o razlici u SQL upitima kod Access-a i SQL CE-a... ko je radio - zna. Postoji podrška za transakcije, referencijalni integritet, 128-bitnu enkripciju itd. itd. (ima na Internetu informacija). Osim toga - SQL CE je brži od Access-a, pogotovo kod velikih baza (tako pokazuju i testovi)...

E, sad: zašto ne dijelim tvoj stav (ma da se slažem sa tobom), ali zašto ne bih toliko potencirao Express verzije - odgovor treba pronaći u tezi koju si i ti neki dan ponovio: "upotrebiti resursa onoliko koliko je minimalno neophodno da bi se obavio zadatak".

Evo, svjedok sam brojnih "modernih" aplikacija koje kao database engine koriste SQL Server Express Edition. Sve bi to bilo lijepo - da tim aplikacijama zaista treba takav RDBMS, i da se zaista barata nekim podacima - međutim NE - u konkretnom slučaju radi se i o CBT-ovima (Computer Based Training-u) gdje baza služi ISKLJUČIVO da bi se u nju unio spisak od najčešće 1 ili 2 čovjeka i rezultat testa koji se uradi jednom i ko zna kad. I, onda, da bi moj kolega na svoj laptop (skromnih hardverskih karakteristika) imao cio set ovih CBT-ova - treba da, u okviru instalacije CBT-a, podigne i odgovarajuću instancu SQL Server-a Express Edition-a.

I tako on ima ukupno 6 (slovima: ŠEST) instanci SQL Server Express Edition-a koji mu proždiru hardver (ne smijem ni da ulazim u to kako je programer podesio Recovery Mode i sl. i da li će mu Transaction Log progutati prostor na hard disku tokom vremena, ali srećom nema veliki broj transakcija - bar se nadam...). I onda on mene moli da mu ubrzam računar koji je počeo da se guši - a sve što mu mogu jeste - da ga naučim da gasi i pokreće servise (odnosno - kreiram mu batch skripte) jer programer pametnjaković nije htio da se bakće sa serijalizacijom objekata i kolekcije ili upotrebom neke embedded baze (pa i Access baze) nego je očekivao da krajnji korisnik sam nauči što je servis, koji servis predstavlja database servis, koje instance, kako ga pokrenuti, stopirati itd. A potom je izašao i Security update za server koji nije htio da se instalira iz nekog neznanog razloga, pa je po neuspješnoj instalaciji Windows Update sam gasio servis i stopirao rad SQL Server Express edicije, i to u toku rada...

I što onda? Treba uz softver koji se sastoji od 1 forme i 15 PDF fajlova vršiti i deployment database administratora koji će da održava server i otklanja nastale probleme? To je po meni, u najmanju ruku, cumbersome!

Zato sam ja gadljiv na takva scenarija gdje se na muvu puca iz atomskog oružja, žrtvujući pri tome brojne resurse gdje nema nikakve potrebe.

Ako čovjek treba da uskladišti jednu tabelu sa 20 hiljada redova, i da iz nje pokupi podatke/migrira u drugu bazu - što će mu mrežna baza?

Takođe - ne znam zašto si imao problema sa migracijom podataka iz SDF-a u MDF? Naravno da ne možemo očekivati utility za direktnu konverziju SDF-a u MDF, jer to nije konverzija JPG-a u PNG - ali se podaci mogu prenositi vrlo lako, i postoji čitava plejada servisa za to (od kojih i Sync Services), ali i native podrška koja se može aktivirati prostim wizard-ima u Visual Studiju.

Na kraju krajeva (kad sam već ovoliko odužio - mogu još jedan red)... a sklon sam oduživanju... užas... - ne kažem ja da je SQL CE bolja baza od SQL Express-a, nego mislim da je u određenim okolnostima PRIMJENJIVIJA.

To je sve. :)

Pa apsolutno se slazem sa tobom oko vecine stvari (sem stvari na koje cu u nastavku da odgovorim). I taj CBT program jest lose uradjen iz dva razloga:

1. Da, zaista je mogao da koristi CE (sto se poklapa sa single-user primenom CE-a sa kojom sam se slozio)
2. Programer je u nedostatku boljeg izraza nesposoban jer SQL Express ne zahteva podizanje N instanci kao sto je to MSDE zahtevao, dovoljna je jedna instanca sa dozvoljenim user mounted bazama i sve aplikacije kojima treba mogu da dele tu instancu.

Sve je to prihvatljivo i ja to nisam ni opovrgavao, ono gde ja imam sukob sa CE-om je sto je 'novi maslac', maze se i gde treba i gde ne treba samo zato sto je nov. I nije mu mesto u LAN multi-user aplikacijama, kao sto ni expressu nije bilo mesto u tvom primeru, jer ako imas LAN i vise korisnika sigurno imas bar negde da stavis instancu Expess-a i da sebe resis svih postojecih i buducih problema (i to tad postaje minimum resursa koji ti trebaju).

E sad ostalo

To nije problem, to je single-user mode i u njemu nema konkurencije samim tim ni mehanizama za resavanje iste. Problem nastaje kad se N in-process instanci zakaci na sdf file na LAN share-u.

Zasto ne? Logisticke gluposti koje nisu korisni podaci imas i u server instancama (u master-u i u sistemskim tabelama u svakoj bazi), ne vidim nikakav problem da Access kreira svoju "skrivenu" table strukturu u sdf-u. Da li ima logike ili nema je diskutabilno (po meni ima zbog konsolidacije o kojoj sam pisao) ali se ovde lako moze citati izmedju redova, Jeta nema i nece ga biti za 64bit platofrmu niti ce biti nove verzije posle 4.0, poverovao bih ti da se ista od ovoga desava i da MS pokazuje bilo kakvu nameru da odrzi Jet u zivotu. A nesto mora da drzi Accessove podatke, ako nije Jet onda je CE (ili express ).

Nemam problem sa tim, samo mislim da je glupo odradjeno. MDF format nije naucna fantastika i koriscenje njega uz ignorisanje onih metadata elementata koje CE ne razume (npr SP) bi omogucilo laksi upgrade sa edicije na ediciju i npr user mount iz express verzije, itd, nista vise i nista manje. Nije nesto zbog cega bi umro, ali bi npr mogao sinhronizaciju da odradim u nekim situacijama sa par query-a umesto sa nadolazecm sync servisom, zar ne?

---

Pa ti sinhronizaciju i možeš obaviti sa par query-ja - ne moraš koristiti Sync Services. To Sync Services zapravo i radi. Ali tu nije kraj razvoju... biće još noviteta, samo da bude ideja i feedback-a...

Nego - problem sa SQL CE ne nastaje ni u više-korisničkom režimu.



Naravno - ne treba tjerati mak na konac; ali ne treba ni pretjerivati, a mislim da su novopečeni database programeri generalno vrlo skloni pretjerivanju i da slabo misle (zapravo i ne misle) na optimizaciju, što se manifestuje brojnim aplikacijama kakve imamo (no to je široka tema), da smo došli do toga da običan CBT ili katalog rezervnih djelova (isti slučaj) u nekoj bliskoj budućnosti bude višeslojna aplikacija, pa da se uz bazu pojavi potreba za aplikacionim slojem ...

No, nažalost, nije to samo slučaj sa nama... To se vidi i kod Microsoft-a koji je, primjera radi, u Windows Small Business od verzije 2003 pa nadalje - za gotovo svaku serversku komponentu namijenio jednu ili više express verzija SQL Server baze, i to različitih verzija. I onda imamo WSUS koji naduva MDF veličine jedva ispod kritičnog praga od 4GB sa LDF-om od 2 i više GB, i tako nadalje redom...

Šta ćeš... opustili se programeri... Najlakše je, zaista, desni klik: create database, create table, drag na formu itd., i onda - deployment: include SQLSERVER-EXPRESS, rebuild... i program gotov... ja ih zovem "drag & drop programeri", i čim sam vidio "Data Environment" u verziji VB-a 5 znao sam da se crno piše softverskoj industriji i korisnicima i da je vrag odnio šalu ... :)

---

Ovo drugo dolje - ne bih nagađao što bi moglo biti i šta će biti sa JET-om i Access-ovim meta-podacima... neka o tome razmišlja Microsoft, ja i ne koristim Access. :)

Koliko ja znam SDF ne moze da se mountuje u jace edicije SQL servera i samim tim ne mogu da se rade distributed transakcije ni query-ji koji bi ukljucivali jednu sdf i jednu mdf bazu. Zato oni prave Sync Services da bi to resili, sto opet nije problem, ja samo tvrdim da je sve to moglo unapred da se resi kroz primenu mdf fajla, pa ti ne bi trebali ni sync services, ni custom alatke ni rucne copy-paste metode. Samo su sebi i nama napravili problem bez preke potrebe.


Nisi obratio paznju na ono sto sam mislio pa cu da citiram sebe: "samim tim sto nema centralnog kontrolera baze nema ni centralne lokacije za memorijsko kesiranje stranica i kriticnih podsistema kao sto je locking engine, pa isto kao Jet i SQLCE u multi-user rezimu mora da odrzava locking tabele u file strukturi sa serijalizovanim pristupom, i kako god da spinuju tu cinjenicu to ne moze da bude skalabilno u nekoj SOHO varijanti sa rastucim brojem korisnika".
Da bih ti prezentovao zasto je to "lose" zamisli sledeci scenario: pera mika i zika koriste lokalnu aplikaciju koja podatke cita iz XML fajlova na LAN share-u gde je svaki record u jednom fajlu. Kad mika hoce da promeni neki podatak on vikne peri i ziki: "Ja sad menjam podatak o racunu broj 12345, ne dirajte". Mozda je smesno, ali ovo je pravi pravcati multi-user sistem sa resenim concurency-em i ima row level locking, zar ne? I sad gazda firme dobije venture capital jer ima mnogo jak biznis plan i zaposli jos 12 radnika, koji pakao ce sad da nastane sa dovikivanjem... Sad zamisli mali upgrade gde objava locka ide kroz posebnu locking strukturu na istoj shared lokaciji na LAN-u i dobices ono sto je esencijalno locking mehanizam SQL CE-a. Malo je bolji od dovikivanja ali nije mnogo daleko i ne skalira se lepo sa brojem korisnika jer je samo locking mehanizam slaba tacka (serijalizvan pristup file systemu na share-u). Rece da nisi koristio Access i mislim da je to u principu razlog zasto nisi ranije naleteo na ovaj problem jer Jet radi na identican nacin.



Hehe, a SQL CE se radi drugacije? A da, imas jos jedan korak "Add sdf to project..."

---

Ti misliš da je to problem - a ja opet kažem da je to suština; i nekada smo koristili SQLite i mučili se sa razlikama u SQL sintaksi između njega i SQL Servera, samo da bi imali embedded bazu, bez ikakvih mehanizama za sinhronizaciju - pa je prodor i inovacija Compact Edicije na desktop računare - dobrodošla! A kome treba Express Edition - ne treba, naravno, da koristi Compact Edition, i ne vidim suštinu tih kritika: imaš Compact Edition, Access i 6 verzija RDBMS SQL Server-a + 3rd party baze... Zaista puna kapa... nema razloga da se Compact ediciji zamjera što nije RDBMS, kao što nema razloga da se Windows klijentu zamjera što nije server.

Možeš da mountuješ SDF (v3.5) u Management Studio SQL Server-a 2008 i Visual Studio 2005/SP1 i VS 2008, a ima more 3rd party programa za kopiranje podataka iz MDF-a u SDF (neki su i open-source: http://www.codeproject.com/KB/database/SqlCompactCoptUtility.aspx - treba samo malo dobre volje i strpljenja). Uostalom: kome je teško da napiše rutinu za kopiranje podataka iz jedne baze u drugu - taj ne treba ni da se bavi programiranjem.

---

Što se drugog dijela odgovora tiče - da, u pravu si - međutim - u teoriji, i opet se otvara pitanje koje se otvorilo na jednoj drugoj temi u .NET podforumu - a sve zbog zaključavanja record-a i suprotnih mišljenja na tu temu. Poznavajući ADO.NET mehanizam i logiku disconnected režima - ne vidim problem ni u ovome, kao ni sa Access bazom. Konekcija se otvori zarad potrebe izvršavanja upita i trenutno zatvara. Sve se ovo odvija toliko trenutno - da tebi u realnim okolnostima to ne čini nikakvu razliku. Pa zaboga - i gomila Web sajtova sa ogromnim brojem hit-ova i dalje koristi Access bazu za podatke...

A Access za development poodavno ne koristim, i na to sam mislio - ali imam još jedan slučaj u firmi gdje studenti rade sa CBT bibliotekom u mreži gdje se praćenje rezultata i korisnika, lokacije foldera CBT-a, statički podaci itd. bilježe u Access bazi kojoj u datom trenutku pristupa 6 + 6 studenata, radeći sa CBT-ovima cio dan i to ne radi munjevito brzo - ali radi sasvim zadovoljavajuće, i to godinama i to na desetine hiljada lokacija širom svijeta po istovjetnom principu (politika Norveškog Seagull-a koji razvija ovakve CBT-ove, a lider je na tom polju)...

Eto - to je kontrast onom moj prethodnom primjeru isto na temu CBT-ova - kao sušta suprotnost ovome... čisti overkill...

---

Dakle - suština mog posta jeste prilagođavanje potrebama u realnom okruženju i eliminacija potencijalnih problema koji se mogu pojaviti tokom daljeg rada.