acum, că ați văzut diferite arhitecturi și opțiuni de motor de baze de date disponibile, veți dori să exploreze punctele de decizie și parametrii pentru a face decizia upsizing.
cea mai importantă parte în acest proces este înțelegerea faptului că nu toate Accessdatabases trebuie să fie upsized. De fapt, majoritatea aplicațiilor de acces nu ar trebui să fie mărite—costul și întreruperea afacerii nu este pur și simplu o utilizare rentabilă a resurselor dvs. Aceste baze de date funcționează bine în fiecare zi și nu au nevoie de atribute precum scalabilitatea, securitatea și fiabilitatea 100%. Dintre toatebaze de date de acces din organizația dvs., doar câțiva sunt candidați pentru redimensionare.
în plus, din lista de candidați pentru upsizing, o majoritate poate fi upsizedusing un proces rentabil în cazul în care numai datele sunt mutate în SQL Server. Toate funcționalitățile aplicației în ceea ce privește formularele și rapoartele sunt păstrate în Acces. Doar cel mai mic procent de proiecte de mărire implică rescrierea aplicației Accessapplication într-un mediu nou, cum ar fi .NET.
următoarea secțiune examinează fiecare dintre domeniile cheie implicate în planificarea bazei de date și discută modul în care Access efectuează în fiecare zonă.
securitate
Microsoft Access oferă trei mecanisme de securitate diferite.
- parole de bază de date: atribuiți o parolă unei baze de date. Numai utilizatorii care cunosc parola pot deschide baza de date.
- Jet Workgroup Security: utilizatorii, grupurile și permisiunile de obiecte pot fi definite pentru a restricționa cine poate vizualiza/edita datele și ce pot rula. Securitatea grupului de lucru este disponibilă pentru bazele de date MDB, dar nu și pentru bazele de date ACCDB.
- criptarea fișierelor: conținutul bazei de date poate fi criptat la nivel de fișier. Criptarea ACCDB este semnificativ mai bună decât criptarea pentru MDB-uri.
din păcate, aceste mecanisme nu sunt nici robuste, nici fiabile. Parolele bazei de date utilizează un mecanism de criptare foarte simplu. De fapt, eliminarea unei parole a bazei de date Access este o chestiune simplă, având în vedere că „eliminatorii” de parole gratuite și comerciale sunt ușor de găsit pe web. În timp ce utilizatorii Access nu pot fi preocupați de astfel de lacune, managerii IT ar trebui să fie cu siguranță.
în timp ce Jet Workgroup Security este mai robust, acesta lasă în continuare conținutul întregii baze de date MDB deschis din sistemul de fișiere. Deoarece toate datele și Codul tabelului sunt stocate la vedere simplă, este o chestiune banală să deschideți un fișier MDB într-un editor compatibil cu șirul și să vizualizați codul, parolele și datele tabelului.
în cele din urmă, deoarece Access necesită permisiuni complete de citire pentru toți utilizatorii la fișierul bazei de date reale, oricine poate vedea o unitate de rețea partajată poate pleca cu baza de date pe un disc sau CDR sau o poate trimite prin e-mail în afara organizației dvs.
dacă securitatea este importantă, SQL Server este mult mai sigur decât Microsoft Access, Excel, Word sau orice alt program care stochează fișierele sale direct pe hard diskul accesibil utilizatorului.
fiabilitate și întreținere
fiabilitatea este unul dintre reperele cheie de examinat atunci când se ia în considerare creșterea dimensiunii. Într-adevăr, pentru multe aplicații critice pentru misiune, fiabilitatea este cel mai important aspect. Microsoft Access nu este la fel de fiabil ca SQL Server din mai multe motive.
corupția bazei de date
când bazele de date Microsoft Access/Jet întâmpină o eroare internă neașteptată sau o problemă de conexiune, acestea pot deveni corupte. O bază de date coruptă blochează în general toți utilizatorii bazei de date și are ca rezultat pierderea datelor și întreruperea afacerii.
bazele de date Microsoft Access/Jet sunt mai predispuse la corupție decât SQL Server din mai multe motive. Deoarece Access / Jet utilizează un model de partajare de fișiere, toți utilizatorii dețin simultan conexiuni active la date. Dacă oricare dintre acești utilizatori pierde în mod neașteptat conexiunea, baza de date poate deveni coruptă. Pierderea conexiunii se poate întâmpla dacă conexiunea de rețea a utilizatorului este intermitentă, versiunile driverului nu sunt actuale sau versiunile conflictuale ale DLL-urilor Jet sunt utilizate pentru a citi același fișier de bază de date.
Microsoft Access include un utilitar Compact/Repair, dar corupția gravă a bazei de date nu este rezolvată de acest utilitar. Serviciile de reparații ale terților sunt disponibile, dar acest lucru necesită trimiterea bazei de date afectate într-o altă locație, plata unei taxe și așteptarea returnării acesteia cu rezultate mixte.
probleme de întreținere
Windows permite copierea unei baze de date Microsoft Access chiar dacă oamenii o au deschisă, astfel încât să puteți crea o copie de rezervă, dar aceasta poate fi o problemă dacă cineva modifică datele în momentul copierii fișierului.
compactarea unei baze de date Microsoft Access necesită ca toți utilizatorii să fie în afara bazei de date, ceea ce este problematic pentru soluțiile care rulează 24/7. O blocare este plasată în baza de date la nivel de fișier (*.ldb sau *.fișiere laccdb) de îndată ce este deschis de primul utilizator.
într-un mediu cu mai mulți utilizatori, Microsoft Access nu vă spune cine se află în prezent în baza de date, deci poate fi o durere de cap administrativă pentru a scoate oamenii din sistem. Programul nostru Total Access Admin vă permite să monitorizați utilizatorii care intră și ies din Baza de date în timp real, ceea ce ajută și poate compacta baza de date după ce toată lumea iese, dar nu este o caracteristică încorporată a Microsoft Access.
este adesea dificil să coordonezi procesul de asigurare a tuturor utilizatorilor să se deconecteze de la o aplicație Access înainte de a face o copie de rezervă.Scenariile tipice implică utilizatorii care își părăsesc computerele atunci când părăsesc biroul pentru ziua respectivă. Acest lucru lasă baza de date deschisă și software-ul de rezervă nu va ficapabil să copieze în mod fiabil fișierul bazei de date. Adesea, acest lucru este detectat numai după ce copia de rezervă eșuează, lăsând administratorul de sistem să urmărească problema și să spere că este rezolvată înainte ca următoarea copie de rezervă să ruleze.
în plus, Microsoft Access nu este auto-tuning ca SQL Server. Nu revendică automat spațiul bazei de date pierdute sau nu optimizează indexurile și interogările. Această întreținere se realizează prin rularea funcției reparare / compact. Programul nostru total Visual Agent vă permite să automatizați acest lucru într-un program pe care îl specificați și să mențineți o pistă de audit, dar nu este o caracteristică încorporată a Microsoft Access.
dacă o organizație nu face backup în mod regulat pentru bazele de date desktop individuale, utilizatorii pot crea baze de date Access pe PC-urile lor care nu sunt niciodată salvate sau întreținute. Organizațiile le pot trata ca date de utilizator care pot fi pierdute ca și cum ar fi o foaie de calcul Excel sau un document Word, dar ar trebui să existe politici mai bune, astfel încât utilizatorii să își poată salva bazele de date în care este furnizată administrarea de bază a sistemului.
bazele de date Microsoft Access trebuie să fie susținute pentru recuperarea în caz de dezastru și compactate periodic pentru a rămâne sănătoși. Un sistem automatizat ar trebui implementat pentru a avea grijă de asta pentru numeroasele baze de date Access care există astăzi și cele create în viitor. SQL Server upsizing ar trebui să fie luate în considerare pentru bazele de date în cazul în care astfel de procese automate nu pot fi puse în aplicare din cauza utilizării continue a bazei de date sau costul de a pierde orice date este mare.
scalabilitate
scalabilitatea este definită ca abilitatea unei aplicații de a funcționa într-un mod acceptabil pe măsură ce numărul de utilizatori sau procese care apelează aplicația crește. În unele situații, Microsoft Access / Jet nu poate scala pentru a susține cererea din Baza de date.
Split Database Architecture
înainte de a face upsizing, baza de date Access ar trebui să aibă o arhitectură de baze de date Split. Aceasta separă baza de date a aplicației utilizator de baza de date partajată back-end. Front-end link-uri de baze de date de aplicare la baza de date partajată și upgrade-uri sunt mai ușor, deoarece datele nu trebuie să fie modificate pentru noile versiuni (cu condiția structuri tabele nu sunt modificate). Pentru mai multe informații, consultați articolul nostru Despre Microsoft Access Split Database Architecture pentru a sprijini mediile multiutilizator, pentru a îmbunătăți performanța și pentru a simplifica mentenabilitatea. Arhitectura bazei de date divizată va ajuta, de asemenea, într-un efort de extindere pentru a păstra front-end-ul de acces existent.
dacă o singură copie a unei baze de date Microsoft Access se află pe o unitate de rețea și este deschisă de mai mulți utilizatori simultan, este posibil să aveți o problemă de scalabilitate. Dar care ar trebui să fie abordate prin utilizarea unei arhitecturi de baze de date divizat, mai degrabă decât upsizing la SQL Server.
Numărul de utilizatori simultani
au existat mituri despre bazele de date Microsoft Access care nu pot suporta mai mult de 20 de utilizatori. Acesta ar fi putut fi cazul când Microsoft Access a fost introdus în 1992, dar acest lucru nu a fost cazul de ceva timp.
Microsoft Access permite tehnic până la 255 de conexiuni pe bază de date. Asta înseamnă că poate fi folosit pentru aplicații pentru echipe de multe ori, dacă nu toți trebuie să-l folosească în același timp.
numărul de conexiuni/utilizatori pe care o bază de date Access le poate suporta este dictat de cât de bine a fost proiectată și implementată aplicația. O aplicație de acces bine concepută poate suporta peste 100 de utilizatori simultani cu performanțe decente. Pe de altă parte, o aplicație de acces slab proiectată poate rula la un crawl cu doi utilizatori. Sau unele procese sunt doar consumatoare de timp și va fi lent, indiferent de ce bază de date este utilizat. Nu este vorba despre tehnologie, ci despre implementare.
din păcate, multe baze de date Access nu sunt bine concepute sau implementate cu cele mai bune practici. Acest lucru se datorează faptului că majoritatea bazelor de date Access sunt create de utilizatori care pur și simplu nu au experiența sau cunoștințele necesare pentru a crea aplicații de baze de date profesionale. Acestea sunt construite în timp și noi caracteristici și modele de date sunt însăilate pe măsură ce apare nevoia. Rezultatul este o soluție generală care nu poate suporta în mod fiabil mai mult de câțiva utilizatori.
nu upsize aplicații Microsoft Access din motive de număr de utilizatori în cazul în care numărul de utilizatori simultane este relativ scăzut. Upsizing ar trebui să fie luate în considerare în cazul în care unul are nevoie pentru a sprijini 100+ utilizatori simultane și mai mult în viitor.
dimensiunea maximă a bazei de date
fiecare bază de date Microsoft Access are o dimensiune maximă de 2 GB. Aceasta este o mulțime de date text și numerice, dar poate fi depășită cu ușurință dacă fișierele și grafica sunt stocate. Pentru marea majoritate a bazelor de date Microsoft Access, aceasta este mult mai mare decât va obține vreodată baza de date. Uneori, bazele de date devin mari, dar un compact îl reduce de obicei la o dimensiune mai rezonabilă. Asigurați-vă că decompilați și bazele de date Microsoft Access din când în când la compactare.
cu o arhitectură de baze de date divizată, o aplicație Microsoft Access se poate conecta la date din mai multe baze de date Microsoft Access care adaugă până la mai mult de 2 GB. Desigur, acesta nu este un design bun dacă datele nu ar trebui împărțite în mai multe tabele sau baze de date.
Upsizing ar trebui să fie luate în considerare în cazul în care baza de date depășește 1 GB sau va depăși 2 GB în viitorul apropiat.
diferite versiuni ale Microsoft Access și Jet
există multe versiuni ale Microsoft Access. O soluție de bază de date Access poate depinde de o anumită versiune a unui format de bază de date Access, se poate baza pe caracteristici care sunt disponibile numai pe anumite versiuni de Access, componente precum ADO și DAO etc. Deși este ușor să distribuiți o bază de date Access utilizatorilor care au acces deja instalat pe computerul lor, nu este atât de ușor să controlați ce versiune de Access este deschisă pentru a o rula.
un PC poate avea mai multe versiuni de Access instalate pe acesta. Deschiderea unui fișier ACCDB sau MDB lansează direct versiunea Access asociată cu extensia de fișier respectivă (de obicei ultima versiune Access care a fost deschisă).
în plus, când a fost introdus Access 2000, noul format de fișier MDB nu era compatibil cu versiunea anterioară Access 97. Deschiderea bazei de date în Access 2000 (sau o versiune ulterioară) ar putea actualiza baza de date la noul format și ar împiedica utilizatorii versiunii vechi să o deschidă, ceea ce a reprezentat o problemă în mediile multiutilizator. Această problemă nu a reapărut de la versiunea din 2000.
programul nostru de pornire Total Access ajută organizațiile să gestioneze și să implementeze bazele de date Microsoft Access pe desktopul fiecărui utilizator și să controleze ce versiune de Access este lansată pentru acesta. Acest lucru facilitează distribuirea aplicațiilor de acces cu o comandă rapidă, iar cea mai recentă versiune a bazei de date este întotdeauna instalată pe computerul fiecărui utilizator. De asemenea, simplifică actualizarea aplicației dvs. de la o versiune de acces la alta.
problemele de gestionare a diferitelor versiuni de Microsoft Access sau de distribuire a actualizărilor bazelor de date Microsoft Access nu sunt rezolvate prin migrarea la SQL Server dacă păstrați front-end-ul Access al bazei de date. Acesta poate fi abordat numai prin înlocuirea completă a Microsoft Access. Acest lucru poate rezolva problema imediată, dar împiedică utilizatorii să-și facă treaba. Am văzut organizații care interzic Microsoft Access doar pentru ca angajații să achiziționeze produse de baze de date mai proaste, deoarece problema bazei de date nu a dispărut. Pentru majoritatea organizațiilor, este imposibil să se utilizeze dezvoltatori profesioniști pentru a crea fiecare bază de date necesară atunci când majoritatea pot fi gestionate de utilizatorii finali.
Performance
Performance este un motiv comun pentru care oamenii doresc să își actualizeze bazele de date Microsoft Access la SQL Server. Există o presupunere că SQL Server va rula mai repede decât o bază de date Microsoft Access. La urma urmei, SQL Server este gestionat de un server separat care trimite doar înregistrările solicitate și poate utiliza mai multe procesoare și mașini pentru a gestiona seturi de date uriașe.
Microsoft Access, fiind bazat pe fișiere, trimite întreaga bază de date, tabel sau index în funcție de cererea de procesare a clientului (PC).
în timp ce acest lucru ar da marginea abordării serverului, am constatat că performanța nu este îmbunătățită în multe situații. Iată câteva motive:
- multe baze de date Access sunt relativ mici (sub 100 MB). Cu hardware-ul actual și conectivitatea la rețea, cantitățile de date transmise sunt aproape instantanee, indiferent dacă sunt câteva înregistrări sau întregul tabel.
- SQL Server efectuează lucrări suplimentare pe care bazele de date Access nu le fac. De exemplu, SQL Server poate menține un jurnal de tranzacții și efectuează întreținere continuă care adaugă aeriene. Am văzut scăderi ale performanței atunci când bazele de date mici sunt mărite la SQL Server.
- SQL Server este conceput pentru a gestiona baze de date foarte mari cu mult peste limita de acces de 2 GB. Nu este optimizat pentru ceea ce ar considera baze de date mici.
- efectuarea interogărilor din diferite surse de tabele legate poate să nu beneficieze de optimizarea SQL Server, deoarece lucrarea este încă realizată de Access
- cache-ul de date de Microsoft Access pentru tabelele Access există deoarece știe dacă datele s-au schimbat. Pentru datele SQL Server, cache-ul în memorie nu este posibil, deoarece este posibil ca datele să se fi schimbat de la ultima solicitare.
- un set prost conceput de tabele, interogări sau cod VBA va rula lent, indiferent dacă datele sunt în Access sau SQL Server.
înainte de a face upgrade la SQL Server din motive de performanță, asigurați-vă că baza de date Access este optimizată astfel încât să ruleze cât mai bine în Access. Mergând la SQL Server nu va rezolva probleme serioase de proiectare a bazei de date și a interogărilor. Fixarea acestora în Access este de fapt mai ușoară decât a face acest lucru mai târziu în SQL Server, astfel încât timpul și efortul petrecut în acest sens sunt păstrate dacă upsize mai târziu.
pentru a vă asigura că baza de date Microsoft Access nu are probleme grave, utilizați programul Total Access Analyzer pentru a documenta și analiza baza de date. Detectează peste 300 de tipuri de erori, sugestii de proiectare și probleme de performanță care vă pot ajuta să vă optimizați baza de date Access.
pentru baze de date Microsoft Access relativ mici, nu upsize la SQL Server numai din motive de performanță. Poate exista o scădere a performanței după creștere. Căutați modalități de optimizare a problemelor de acces înainte de a face investiția în upsize. Este posibil ca problemele de performanță să nu aibă legătură cu stocarea datelor.