[es] - Koji su nedostaci access baza?

Zidar
Canada

Moderator
Član broj: 15387
Poruke: 2600
*.eqao.com

Profil

^{02.06.2004. u 13:54}

Meduljak, tvoj poznanik lupa gluposti. Access kao is vaki drugi prizvod ima svoje lose i dobre strane. I kao i svaki drugi priozvod, namenjen je oderedjenom segmentu trzuista i odredjenoj grupi problema. koliko ces problema imati u praksi, zavisi od toga koliko poznajes snagu i slabosti prizvoda pa se shodno tome organizujes.

Bazu mozes unistiti i bez nestanka struje, ako postavis sistem an pogresan nacin, sto je veoma lako. Pre nekoliko meseci sam mislim o tome ovde govorio (Dobro: azdvajanje sistema na fajl sa podaciama i aplikaciju, svaki korisnik da ima svoju lokalnu kopiju itd.., Lose: kontra od ovoga - podaci i aplikacija u istom fajlu, fajl stoji na serveru i vise korisnika ga otvara od jednom)

Losa strana accessa je sto ga pravi Microsoft (isto kao i MS SQL) pa ima stavri koje su aljkavo odradjene ali tu nema pomoci. Access nema triggere i stored procedures. Za stored procedures nema veze, to je programski kod. Access podrzava mnogo manje korisnika nego MS SQL ili Oracle. Access nije pogodan back end za web aplikacije, ali moze da posluzi.

Sto se tice nestanka struje i gubitaka podataka, aplikacija pisana u Accessu ima daleko vise sanse da sacuva i taj poslednji podatak, nego recimo VB aplikacija na Access back endu. Zasto - zato sto Access gleda direktno u tabele i podaci se snimaju (Save) automatski i bez intervenciej korisnika. I kako pametno rece Simke, ima i back up svoju ulogu celom poslu.

Spavaj mirno. Access te nece izneveriti ako umes da ga koristis na pravi nacin. Price tog tipa poticu od ljudi koji nikad nisu koristili Access ali imaju potrebu da nesto kazu, pa makar i glupo. Veruj Simketu i meni jer mi zaradjujemo za zivot radeci i u Accesu izmedju ostalog.

:-)

:-)

^{02.06.2004. u 13:54}

Zidar
Canada

Moderator
Član broj: 15387
Poruke: 2600
*.eqao.com

Profil

Re: Koji su nedostaci access baza?

^{03.06.2004. u 14:01}

Back Up znaci povremeno praviti kopije fajlova na neko drugo mesto, na trake, CDs, ZIP drives i slicno. ZNaci, ako su podaci jako vazni, u odredjenom vremenskom intervalu pravi se kopija koja se cuva ne nekom ediju na nekom drugom mestu. Frekvenciaj bekapa zavisi od vaznosti podataka. U small business, za robno knjigovodstvo, fakturisanje, narudzbe, vecina radi back up na kraju dana. Posto ima 5 radnih dana, treba ti 5 traka ili RW CD ili ZIP diskova, koje nazoves Pon,Uto,Sre.... I na kraju svakog dana snimis celu bazu (.MDB fajl s apodacima) na back up medijum. posle 5 dana, recikliras medijume. I tako uvek imas kopije podataka koji su stari do 5 dana. U slucaju neke nevolje - tvoj originalni MDB faj je unisten - uzmes najsveziji back up i radis s time. Izgubio si podatke za jedan dan i to je sve. Ako ne mozes da priustis da izgubis podatke za poslednji dan, mozes da radis back up na svaki sat. Cesce od toga mislim da prakticno nije izvodljivo. Ako ti treba absolutna sigurnost podataka, onda ides na SQl server koji moze da radi mirrorring - pored radne baze odrzava jos jednu koja je 100% slika radne baze. i opet radi back up na trake i trake cuvas van mesta gde su serveri jer neko moze da provali i fizicki odnese servere. Ili moze server room da izgori u pozaru. Znaci, back up mor a da se radi i da se kopije cuvaju na sigurnom, gde ne mogu da izgore ili budu ukrasdene, ba r ne u isti cas kad i original.

Recovery znaci spasiti ostecene podatke ako je ikako moguce. Access iam komande Compact i Repair. U starijim vezijama to su dve komande, u 2K2 mislim da je to pod jednom komandom. Kad dobijes poruku "MDB file format not recognized" ili "unreadable" probas prvo Repar pa onda Compact. Cesto repair pomogne. Comact treba raditi redovno, sto cesce, da se ne bi fajl pokvario (get corrupted). Aplikacioni fajlovi se cesce kavre i treba ih kompaktovati cesto. Ako se stalno nesto dodaje ili brise ili menja (nesto=forme, reporti, kveriji), fajl moze da se pokvari. Kad god dodas ili menjas neki objekat u design modu, rekompiliraj projekat (Compile) pa onda Compact. Sa malo srece, neces nikada morati da radis Repair.
Ako vise (>1) korisnika otvore u isto vreme isti MDB fajl koja se nalazi na serveru, vrlo je verovatno da ce se taj aplikacioni MDB fajl vrlo brzo pokvariti i bice potreban repair. Zato se nikada sebe ne dovodis u situaciju da vise od jedne osobe otvara jedan isti aplikacioni fajl. Svaki korisnik treba da ima svoju kopiju aplikacije na svom C:\ drajvu. Znaci, borba protiv kvarenja falova pocinje osmisljavanjem sistema. Podsecam da kada se svi linkuju na daat fajl to nije isto kao da su svi otvorili taj fajl. Ne daj boze da svi otvore faj sa File Open u istom momentu

Znaci, redovan dnevna rutina bi bila:
1) Comapct fajl sa podacima i aplikaciju
2) back up fajl sa podacima.
Pretpostavlja se da je sistem postavljen kako treba - data fajl na serveru, aplikacioni fajlovi na lokalnim masinama i tabele linkovane iz data fajla u lokalne aplikacije.

Mnoge aplikacije i sistemi nisu postavljeni kako treba i normalno da dolazi do problema i ljudi onda zakljuce da je Access s***** od programa. Ko ne ume, neka mu i bude tako.

;-D)

^{03.06.2004. u 14:01}