nu hvor du har set de forskellige arkitekturer og databasemotorindstillinger, skal du undersøge beslutningspunkterne og parametrene for at træffe beslutningen om at øge størrelsen.
den vigtigste del i denne proces er at forstå, at ikke alle Accessdatabaser skal øges. Faktisk bør et flertal af Adgangsapplikationer ikke være større—omkostningerne og forstyrrelsen i virksomheden er simpelthen ikke en omkostningseffektivanvendelse af dine ressourcer. Disse databaser fungerer fint dagligt og har ikke brug for attributter som skalerbarhed, sikkerhed og 100% pålidelighed. Af alleadgangsdatabaser i din organisation er kun få kandidater til størrelse.
derudover kan et flertal fra listen over kandidater til størrelse øges ved hjælp af en omkostningseffektiv proces, hvor kun dataene flyttes til en server. Alle programmets funktionalitet i form af formularer og rapporter holdes i adgang. Kun den mindste procentdel af opgraderingsprojekter involverer omskrivning af Accessapplikationen i et nyt miljø som .NET.
det følgende afsnit undersøger hvert af de nøgleområder, der er involveret i databaseplanlægning, og diskuterer, hvordan Access klarer sig i hvert område.
sikkerhed
Microsoft Access tilbyder tre forskellige sikkerhedsmekanismer.
- Databaseadgangskoder: Tildel en adgangskode til en database. Kun brugere, der kender adgangskoden, kan åbne databasen.
- Jet-Arbejdsgruppesikkerhed: Brugere, Grupper og objekttilladelser kan defineres for at begrænse, hvem der kan se/redigere data, og hvad de kan køre. Arbejdsgruppesikkerhed er tilgængelig for MDB-databaser, men ikke ACCDB-databaser.
- filkryptering: databasens indhold kan krypteres på filniveau. ACCDB-kryptering er betydeligt bedre end kryptering for MDB ‘ er.
Desværre er disse mekanismer hverken robuste eller pålidelige. Databaseadgangskoder bruger en meget enkel krypteringsmekanisme. Faktisk er det simpelt at fjerne en adgangskode til Adgangsdatabasen, da gratis og kommerciel adgangskode “fjernere” let findes på nettet. Mens Access-brugere muligvis ikke er bekymrede over sådanne bortfald, bør IT-ledere bestemt være det.
mens Jet-arbejdsgruppens sikkerhed er mere robust, lader den stadig indholdet af hele MDB-databasen være åben fra filsystemet. Da alle tabeldata og kode er gemt i almindelig visning, er det en triviel sag at åbne en MDB-fil i en strengkompatibel editor og se kode, adgangskoder og tabeldata.
endelig, fordi adgang kræver fuld læsetilladelser for alle brugere til den faktiske databasefil, kan alle, der kan se et delt netværksdrev, gå ud med databasen på en disk eller CDR eller e-maile den uden for din organisation.
hvis sikkerhed er vigtig, er Microsoft Access, ord eller ethvert andet program, der gemmer sine filer direkte på harddisken, der er tilgængelig for brugeren.
pålidelighed og vedligeholdelse
pålidelighed er et af de vigtigste benchmarks, der skal undersøges, når man overvejer at øge størrelsen. For mange missionskritiske applikationer er pålidelighed faktisk den vigtigste overvejelse. Microsoft Access er ikke så pålidelig som Microsoft-serveren af flere grunde.
Databasekorruption
når Microsoft Access/Jet-databaser støder på en uventet intern fejl eller forbindelsesproblem, kan de blive korrupte. En korrupt database låser generelt alle brugere af databasen og resulterer i tab af data og forretningsforstyrrelser.
Microsoft Access/Jet-databaser er mere tilbøjelige til korruption end Microsoft-Server af en række årsager. Da Access / Jet bruger en fildelingsmodel, holder alle brugere samtidig aktive forbindelser til data. Hvis en af disse brugere uventet mister forbindelsen, kan databasen blive korrupt. Forbindelsestab kan ske, hvis brugerens netværksforbindelse er intermitterende, driverversioner er ikke aktuelle, eller modstridende versioner af Jet-DLL ‘ erne bruges til at læse den samme databasefil.
Microsoft Access indeholder et kompakt/Reparationsværktøj, men alvorlig databasekorruption er ikke rettet af dette værktøj. Tredjeparts reparationstjenester er tilgængelige, men dette kræver, at den berørte database sendes til et andet sted, betaler et gebyr og venter på, at den returneres med blandede resultater.
vedligeholdelsesproblemer
vinduer tillader kopiering af en Microsoft Access-database, selvom folk har den åben, så du kan oprette en sikkerhedskopi, men det kan være et problem, hvis nogen ændrer dataene på det tidspunkt, filen kopieres.
komprimering af en Microsoft Access-database kræver, at alle brugere er væk fra databasen, hvilket er problematisk for løsninger, der kører 24/7. En lås er placeret på databasen på filniveau (*.ldb eller*.laccdb filer), så snart den er åbnet af den første bruger.
i et miljø med flere brugere fortæller Microsoft Access dig ikke, hvem der i øjeblikket er i databasen, så det kan være en administrativ hovedpine at få folk væk fra systemet. Vores Total Access Admin-program giver dig mulighed for at overvåge brugerne, der går ind og ud af databasen i realtid, hvilket hjælper og kan komprimere databasen, når alle er gået ud, men det er ikke en indbygget funktion i Microsoft Access.
det er ofte vanskeligt at koordinere processen med at sikre, at alle brugere logger af et Access-program, før de foretager en sikkerhedskopi.Typiske scenarier involverer brugere, der forlader deres computere, når de forlader kontoret for dagen. Dette efterlader databasen åben, og sikkerhedskopieringsprogrammet kan ikke pålideligt kopiere databasefilen. Ofte registreres dette først, når sikkerhedskopien mislykkes, hvilket efterlader systemadministratoren at spore problemet og håber, at det er løst, før den næste sikkerhedskopi kører.
derudover er Microsoft Access ikke selvindstillet som f.eks. Det betyder ikke automatisk genvinde tabt database plads eller optimere indekser og forespørgsler. Denne vedligeholdelse udføres ved at køre funktionen repair/compact. Vores Total Visual Agent-program giver dig mulighed for at automatisere dette efter en tidsplan, du angiver, og vedligeholde et revisionsspor, men det er ikke en indbygget funktion i Microsoft Access.
hvis en organisation ikke regelmæssigt sikkerhedskopierer individuelle skrivebordsdatabaser, kan folk oprette Access-databaser på deres pc ‘ er, der aldrig sikkerhedskopieres eller vedligeholdes. Organisationer kan behandle dem som brugerdata, der kan gå tabt, som om det var et regneark eller et orddokument, men bedre politikker bør være på plads, så brugerne kan gemme deres databaser, hvor grundlæggende systemadministration leveres.
Microsoft Access-databaser skal sikkerhedskopieres til katastrofegendannelse og periodisk komprimeres for at forblive sunde. Et automatiseret system bør implementeres for at tage sig af det for de mange Adgangsdatabaser, der findes i dag, og dem, der oprettes i fremtiden. Der bør tages hensyn til databaserne, hvor sådanne automatiserede processer ikke kan implementeres på grund af kontinuerlig brug af databasen, eller hvor omkostningerne ved at miste data er høje.
skalerbarhed
skalerbarhed defineres som en applikations evne til at fungere på en acceptabel måde, når antallet af brugere eller processer, der kalder applikationen, øges. I nogle situationer kan Microsoft Access / Jet ikke skalere for at understøtte efterspørgslen i databasen.
Opdel Databasearkitektur
før du foretager størrelse, skal din Access-database have en delt Databasearkitektur. Dette adskiller brugerapplikationsdatabasen fra back-end delte datadatabase. Front – end-applikationsdatabasen links til den delte database og opgraderinger er lettere, fordi dataene ikke behøver at blive ændret til nye udgivelser (forudsat at tabelstrukturer ikke ændres). Du kan finde flere oplysninger i vores artikel om Microsoft Access Split-Databasearkitektur for at understøtte Flerbrugermiljøer, forbedre ydeevnen og forenkle vedligeholdelsen. Den opdelte databasearkitektur vil også hjælpe med en større indsats for at bevare den eksisterende Adgangsfront.
hvis en enkelt kopi af en Microsoft Access-database findes på et netværksdrev og åbnes af flere brugere ad gangen, kan du have et problem med skalerbarhed. Men det skal løses ved hjælp af en delt databasearkitektur i stedet for at øge størrelsen på serveren.
antal samtidige brugere
der har været myter om, at Microsoft Access-databaser ikke kunne understøtte mere end 20 brugere. Det kan have været tilfældet, da Microsoft Access blev introduceret i 1992, men det har ikke været tilfældet i nogen tid.
Microsoft Access tillader teknisk op til 255 forbindelser pr. Det betyder, at det kan bruges til applikationer til teams mange gange, hvis de ikke alle har brug for det på samme tid.
antallet af forbindelser / brugere, som en Access-database kan understøtte, dikteres af, hvor godt applikationen blev designet og implementeret. En veldesignet Adgangsapplikation kan understøtte 100 + samtidige brugere med anstændig ydelse. På den anden side kan en dårligt designet Adgangsapplikation køre ved en gennemgang med to brugere. Eller nogle processer er bare tidskrævende og vil være langsomme, uanset hvilken database der bruges. Det handler ikke om teknologi, men om implementering.
desværre er mange Access-databaser ikke godt designet eller implementeret med bedste praksis. Dette skyldes, at de fleste Adgangsdatabaser oprettes af brugere, der simpelthen ikke har erfaring eller viden til at oprette professionelle databaseapplikationer. De er bygget over tid, og nye funktioner og datamodeller tackles, når behovet opstår. Resultatet er en samlet løsning, der ikke pålideligt kan understøtte mere end et par brugere.
Forøg ikke Microsoft Access-applikationer af brugertællingsårsager, hvis antallet af samtidige brugere er relativt lavt. Opmåling bør overvejes, hvis man har brug for at støtte 100+ samtidige brugere og mere i fremtiden.
maksimal databasestørrelse
hver Microsoft Access-database har en maksimal størrelse på 2 GB. Det er en masse tekst og numeriske data, men kan nemt overskrides, hvis filer og grafik bliver gemt. For langt de fleste Microsoft Access-databaser er det meget større, end databasen nogensinde vil få. Nogle gange bliver databaser store, men en kompakt reducerer det normalt til en mere rimelig størrelse. Sørg for, at du også dekompilerer dine Microsoft Access-databaser fra tid til anden, når du komprimerer.
med en delt databasearkitektur kan et Microsoft Access-program linke til data fra flere Microsoft Access-databaser, der udgør mere end 2 GB. Det er selvfølgelig ikke et godt design, hvis data ikke skal opdeles på tværs af flere tabeller eller databaser.
opmåling bør overvejes, hvis databasen overstiger 1 GB eller vil overstige 2 GB i den nærmeste fremtid.
forskellige versioner af Microsoft Access og Jet
der er mange versioner af Microsoft Access. En Access-databaseløsning kan være afhængig af en bestemt version af et Access-databaseformat, afhængig af funktioner, der kun er tilgængelige på bestemte versioner af Access, komponenter som ADO og DAO osv. Selvom det er let at distribuere en Access-database til brugere, der allerede har Access installeret på deres PC, er det ikke så let at kontrollere, hvilken version af Access der åbnes for at køre den.
en PC kan have flere versioner af Access installeret på den. Åbning af en ACCDB-eller MDB-fil starter direkte den Access-version, der er tilknyttet filtypen (normalt den sidste Access-version, der blev åbnet).
da Access 2000 blev introduceret, var det nye MDB-filformat ikke kompatibelt med den tidligere Access 97-version. Åbning af databasen i Access 2000 (eller nyere) kunne opgradere databasen til det nye format og forhindre brugere af den gamle version i at åbne den, hvilket var et problem i flerbrugermiljøer. Dette problem er ikke gentaget siden 2000-versionen.
vores startprogram for Total Access hjælper organisationer med centralt at administrere og implementere Microsoft Access-databaser på hver brugers skrivebord og kontrollere, hvilken version af Access der lanceres til den. Dette gør det nemt at distribuere dine Access-applikationer med en genvej, og den nyeste version af din database er altid installeret på hver brugers maskine. Det gør det også nemt at opgradere din applikation fra en version af Access til en anden.
problemer med at administrere forskellige versioner af Microsoft Access eller distribuere opdateringer af Microsoft Access-databaser løses ikke ved at migrere til Microsoft Access-serveren, hvis du beholder Access-frontenden af databasen. Det kan kun løses ved at erstatte Microsoft Access fuldstændigt. Det kan løse det umiddelbare problem, men det forhindrer brugerne i at få deres arbejde udført. Vi har set organisationer forbyde Microsoft Access kun for medarbejdere at købe værre databaseprodukter i stedet, da databaseproblemet ikke forsvandt. For de fleste organisationer er det upraktisk at bruge professionelle udviklere til at oprette hver database, der er nødvendig, når de fleste kan håndteres af slutbrugere.
ydeevne
ydeevne er en almindelig årsag til, at folk ønsker at opgradere deres Microsoft Access-databaser til en server. Der er en antagelse om, at Microsoft Access-serveren vil køre hurtigere end en Microsoft Access-database. Når alt kommer til alt administreres en separat server, der kun sender de ønskede poster, og kan bruge flere CPU ‘ er og maskiner til at administrere enorme datasæt.
Microsoft Access, der er filbaseret, sender hele databasen, tabellen eller indekset afhængigt af anmodningen om, at klienten (PC) skal behandle.
selvom dette ville give kanten til servertilgangen, har vi fundet ud af, at ydeevnen ikke forbedres i mange situationer. Her er nogle grunde:
- mange Adgangsdatabaser er relativt små (under 100 MB). Med nuværende udstyr og netværksforbindelse er mængden af data, der sendes, næsten øjeblikkelig, uanset om det er et par poster eller hele tabellen.
- vi udfører ekstra arbejde, som Access-databaser ikke gør. For eksempel kan vi opretholde en transaktionslog og udfører løbende vedligeholdelse, der tilføjer overhead. Vi har set fald i ydeevne, når små databaser er op størrelse til en server.
- vi er designet til at håndtere meget store databaser langt ud over 2 GB adgangsgrænsen. Det er ikke optimeret til, hvad det ville overveje små databaser.
- udførelse af forespørgsler fra forskellige sammenkædede tabelkilder kan muligvis ikke drage fordel af SERVEROPTIMERING, da arbejdet stadig udføres af Access
- data caching af Microsoft Access for Access-tabeller findes, fordi det ved, om dataene er ændret. Caching i hukommelsen er ikke mulig, fordi dataene kan have ændret sig siden den sidste anmodning.
- et dårligt designet sæt tabeller, forespørgsler eller VBA-kode vil køre langsomt, uanset om dataene er i Access eller på en server.
sørg for, at din Access-database er optimeret, så den kører så godt, som den kan I Access. At gå til
for at sikre, at din Microsoft Access-database ikke har alvorlige problemer, skal du bruge vores Total Access-Analysatorprogram til at dokumentere og analysere din database. Den registrerer over 300 typer fejl, designforslag og ydelsesproblemer, der kan hjælpe dig med at optimere din Access-database.
for relativt små Microsoft Access-databaser må du ikke ændre størrelsen på Microsoft Access-serveren udelukkende af hensyn til ydeevnen. Der kan være et fald i ydeevnen efter stigning. Se efter måder at optimere problemerne i Access, inden du foretager investeringen i størrelse. Ydelsesproblemer kan ikke være relateret til datalagring.