most, hogy látta a rendelkezésre álló különböző architektúrákat és adatbázismotor-beállításokat, meg kell vizsgálnia a továbbfejlesztési döntés meghozatalának döntési pontjait és paramétereit.
ennek a folyamatnak a legfontosabb része annak megértése, hogy nem minden Accessdatabase-t kell növelni. Valójában a hozzáférési alkalmazások többségét nem szabad növelni—a költségek és az üzleti zavarok egyszerűen nem az erőforrások költséghatékony felhasználása. Ezek az adatbázisok napi szinten jól működnek, és nem igényelnek olyan attribútumokat, mint a skálázhatóság, a biztonság és a 100% – os megbízhatóság. Az összes közülhozzáférési adatbázisok a szervezetében, csak néhány jelölt a továbbfejlesztésre.
továbbá, a jelöltek listáját upsized többség lehet upsized using költséghatékony folyamat, ahol csak az adatok kerülnek át az SQL Server. Az alkalmazás összes funkciója az űrlapok és jelentések tekintetében az Access-ben marad. Az upsizing projekteknek csak a legkisebb százaléka foglalja magában az Accessapplication átírását egy új környezetben, például a .NET-ben.
a következő szakasz az adatbázis-tervezés kulcsfontosságú területeit vizsgálja, és bemutatja, hogyan teljesít az Access az egyes területeken.
biztonság
a Microsoft Access három különböző biztonsági mechanizmust kínál.
- Adatbázis-jelszavak: jelszó hozzárendelése egy adatbázishoz. Csak a jelszót ismerő felhasználók nyithatják meg az adatbázist.
- Jet Workgroup Security: a felhasználók, csoportok és objektumengedélyek megadhatók annak korlátozására, hogy ki tekintheti meg/szerkesztheti az adatokat, és mit futtathat. Workgroup security elérhető MDB adatbázisok, de nem ACCDB adatbázisok.
- fájl titkosítás: Az adatbázis tartalma fájlszinten titkosítható. Az ACCDB titkosítás lényegesen jobb, mint az MDB-k titkosítása.
sajnos ezek a mechanizmusok sem robusztusak, sem megbízhatóak. Az adatbázis jelszavak nagyon egyszerű titkosítási mechanizmust használnak. Valójában az Access adatbázis jelszavának eltávolítása egyszerű kérdés, mivel az ingyenes és kereskedelmi jelszó “eltávolítók” könnyen megtalálhatók az interneten. Bár az Access-felhasználók nem aggódhatnak az ilyen megszűnések miatt, az informatikai menedzsereknek biztosan kell lenniük.
bár a Jet Workgroup biztonsága robusztusabb, a teljes MDB adatbázis tartalmát továbbra is nyitva hagyja a fájlrendszerből. Mivel az összes táblaadat és kód egyszerű nézetben van tárolva, triviális dolog egy MDB fájlt megnyitni egy karakterlánc-kompatibilis szerkesztőben, és megtekinteni a kódot, a jelszavakat és a táblaadatokat.
végül, mivel az Access minden felhasználó számára teljes olvasási jogosultságot igényel a tényleges adatbázisfájlhoz, bárki, aki lát egy megosztott hálózati meghajtót, elhagyhatja az adatbázist egy lemezen vagy CDR-en, vagy e-mailben elküldheti azt a szervezeten kívül.
ha a biztonság fontos, az SQL Server sokkal biztonságosabb, mint a Microsoft Access, az Excel, a Word vagy bármely más program, amely fájljait közvetlenül a felhasználó számára elérhető merevlemezen tárolja.
megbízhatóság és karbantartás
a megbízhatóság az egyik legfontosabb referenciaérték, amelyet meg kell vizsgálni a bővítés mérlegelésekor. Valójában sok küldetés szempontjából kritikus alkalmazás esetében a megbízhatóság a legfontosabb szempont. A Microsoft Access több okból sem olyan megbízható, mint az SQL Server.
Adatbázis-sérülés
ha a Microsoft Access/Jet adatbázisai váratlan belső hibával vagy csatlakozási problémával találkoznak, azok megsérülhetnek. A sérült adatbázis általában kizárja az adatbázis összes felhasználóját, és adatvesztést és üzleti zavarokat eredményez.
a Microsoft Access/Jet adatbázisai több okból is hajlamosabbak a korrupcióra, mint az SQL Server. Mivel az Access / Jet fájlmegosztási modellt használ, minden felhasználó egyidejűleg aktív kapcsolatokat tart fenn az adatokkal. Ha bármelyik felhasználó váratlanul elveszíti a kapcsolatot, az adatbázis megsérülhet. Kapcsolatvesztés akkor fordulhat elő, ha a felhasználó hálózati kapcsolata szakaszos, az illesztőprogram-verziók nem aktuálisak, vagy a Jet DLL-ek ütköző verzióit használják ugyanazon adatbázisfájl olvasására.
a Microsoft Access tartalmaz egy kompakt/javító segédprogramot, de ez a segédprogram nem javítja az adatbázis súlyos sérülését. Harmadik féltől származó javítási szolgáltatások állnak rendelkezésre, de ehhez az érintett adatbázist egy másik helyre kell elküldeni, díjat kell fizetni, és meg kell várni, hogy vegyes eredményekkel visszaküldjék.
karbantartási problémák
A Windows lehetővé teszi a Microsoft Access-adatbázis másolását akkor is, ha az emberek nyitva vannak, így biztonsági másolatot készíthet, de ez problémát jelenthet, ha valaki módosítja az adatokat a fájl másolásakor.
a Microsoft Access-adatbázis tömörítéséhez minden felhasználónak ki kell lépnie az adatbázisból, ami problémás a 24/7-et futtató megoldásoknál. A fájl szintjén zár kerül az adatbázisba (*.ldb vagy *.laccdb fájlok), amint az első felhasználó megnyitja.
többfelhasználós környezetben, a Microsoft Access nem mondja meg, hogy ki jelenleg az adatbázisban, így lehet egy adminisztratív fejfájás, hogy az emberek ki a rendszerből. A Total Access Admin program lehetővé teszi, hogy figyelemmel kíséri a felhasználók megy ki és be az adatbázisba valós időben, amely segít, és tömöríteni az adatbázist, miután mindenki kilép, de ez nem egy beépített jellemzője a Microsoft Access.
gyakran nehéz összehangolni azt a folyamatot, amely biztosítja, hogy minden felhasználó kijelentkezzen egy Access alkalmazásból, mielőtt biztonsági másolatot készítene.A tipikus forgatókönyvek azt jelentik, hogy a felhasználók bekapcsolva hagyják számítógépüket, amikor egy napra elhagyják az irodát. Ez nyitva hagyja az adatbázist, és a biztonsági mentési szoftver nem lesz képes megbízhatóan másolni az adatbázisfájlt. Gyakran ez csak akkor észlelhető, ha a biztonsági mentés sikertelen, így a rendszergazda felkutatja a problémát, és reméli, hogy a következő biztonsági mentés futtatása előtt megoldódik.
ezenkívül a Microsoft Access nem önhangoló, mint az SQL Server. Nem téríti vissza automatikusan az elveszett adatbázis-területet, és nem optimalizálja az indexeket és lekérdezéseket. Ezt a karbantartást a javítás / kompakt funkció futtatásával hajtják végre. A Total Visual Agent program lehetővé teszi, hogy automatizálja ezt a megadott ütemezés szerint, és fenntartsa az ellenőrzési nyomvonalat, de ez nem a Microsoft Access beépített funkciója.
ha egy szervezet nem készít rendszeresen biztonsági másolatot az egyes asztali adatbázisokról, az emberek Access-adatbázisokat hozhatnak létre a számítógépükön, amelyeket soha nem készítenek biztonsági mentéssel vagy karbantartással. A szervezetek olyan felhasználói adatokként kezelhetik őket, amelyek elveszhetnek, mintha Excel-táblázat vagy Word-dokumentum lenne, de jobb házirendeknek kell lenniük, hogy a felhasználók elmenthessék adatbázisaikat, ahol az alapvető Rendszeradminisztráció biztosított.
a Microsoft Access adatbázisokról biztonsági másolatot kell készíteni a katasztrófa utáni helyreállításhoz, és rendszeresen tömöríteni kell őket, hogy egészségesek maradjanak. Automatizált rendszert kell bevezetni, amely gondoskodik erről a ma létező és a jövőben létrehozott számos hozzáférési adatbázis esetében. Az SQL Server továbbfejlesztését figyelembe kell venni azoknál az adatbázisoknál, ahol az ilyen automatizált folyamatok nem valósíthatók meg az adatbázis folyamatos használata vagy az adatok elvesztésének költsége miatt.
skálázhatóság
a skálázhatóság az alkalmazás azon képessége, hogy elfogadható módon működjön az alkalmazást hívó felhasználók vagy folyamatok számának növekedésével. Bizonyos helyzetekben a Microsoft Access / Jet nem képes méretezni az adatbázis iránti igényt.
osztott adatbázis-architektúra
a bővítés előtt az Access-adatbázisnak osztott adatbázis-architektúrával kell rendelkeznie. Ez elválasztja a felhasználói alkalmazás-adatbázist a back-end megosztott adat-adatbázistól. A front-end alkalmazás adatbázis linkek a megosztott adatbázis és a frissítések könnyebb, mert az adatokat nem kell módosítani az új kiadások (feltéve, táblák struktúrák nem módosulnak). További információkért tekintse meg a Microsoft Access osztott Adatbázis-architektúráról szóló cikkünket, amely támogatja a többfelhasználós környezeteket, javítja a teljesítményt és egyszerűsíti a karbantarthatóságot. Az osztott adatbázis-architektúra szintén segít a meglévő hozzáférési front-end megőrzésében.
ha egy Microsoft Access-adatbázis egyetlen példánya egy hálózati meghajtón található, és egyszerre több felhasználó nyitja meg, akkor méretezhetőségi probléma léphet fel. De ezt meg kell oldani egy osztott adatbázis-architektúra használatával, nem pedig az SQL Server továbbfejlesztésével.
egyidejű felhasználók száma
mítoszok vannak arról, hogy a Microsoft Access adatbázisai nem képesek 20-nál több felhasználót támogatni. Lehet, hogy ez volt a helyzet, amikor a Microsoft Access-t 1992-ben vezették be, de ez már jó ideje nem így volt.
a Microsoft Access technikailag akár 255 kapcsolatot is lehetővé tesz adatbázisonként. Ez azt jelenti, hogy lehet használni Alkalmazások csapatok sokszor, hogy ha nem minden kell használni egyszerre.
az Access-adatbázis által támogatott kapcsolatok/felhasználók számát az határozza meg, hogy az alkalmazás milyen jól lett megtervezve és implementálva. Egy jól megtervezett hozzáférési alkalmazás több mint 100 egyidejű felhasználót támogathat tisztességes teljesítmény mellett. Másrészt egy rosszul megtervezett hozzáférési alkalmazás két felhasználóval feltérképezhető. Vagy egyes folyamatok csak időigényesek, és lassúak lesznek, függetlenül attól, hogy milyen adatbázist használnak. Valójában nem a technológiáról, hanem a megvalósításról van szó.
sajnos sok Access-adatbázist nem megfelelően terveztek vagy valósítottak meg a legjobb gyakorlatokkal. Ennek oka az, hogy a legtöbb Access-adatbázist olyan felhasználók hozzák létre, akik egyszerűen nem rendelkeznek tapasztalattal vagy ismeretekkel a professzionális adatbázis-alkalmazások létrehozásához. Idővel épülnek, és az új funkciók és adatmodellek szükség esetén hozzá vannak kötve. Az eredmény egy átfogó megoldás, amely nem képes megbízhatóan támogatni néhány felhasználónál többet.
ne növelje a Microsoft Access alkalmazások méretét a felhasználók száma miatt, ha az egyidejű felhasználók száma viszonylag alacsony. Figyelembe kell venni a továbbfejlesztést, ha a jövőben több mint 100 egyidejű felhasználót kell támogatni.
maximális Adatbázisméret
minden Microsoft Access adatbázis maximális mérete 2 GB. Ez sok szöveges és numerikus adat, de könnyen túlléphető, ha fájlokat és grafikákat tárolnak. A Microsoft Access adatbázisok túlnyomó többségében ez sokkal nagyobb, mint amit az adatbázis valaha is kap. Néha az adatbázisok nagyok, de a kompakt általában ésszerűbb méretre csökkenti. Ügyeljen arra, hogy a tömörítés során időről időre dekompilálja a Microsoft Access adatbázisait is.
osztott adatbázis-architektúrával a Microsoft Access alkalmazás több, 2 GB-nál nagyobb Microsoft Access-adatbázis adatait is összekapcsolhatja. Természetesen ez nem jó kialakítás, ha az adatokat nem szabad több táblára vagy adatbázisra osztani.
mérlegelni kell a továbbfejlesztést, ha az adatbázis meghaladja az 1 GB-ot, vagy a közeljövőben meghaladja a 2 GB-ot.
a Microsoft Access és a Jet különböző verziói
a Microsoft Access számos verziója létezik. Az Access-adatbázis-megoldás függhet az Access-adatbázis-formátum egy adott verziójától, támaszkodhat olyan funkciókra, amelyek csak az Access bizonyos verzióin érhetők el, olyan összetevőkre, mint az ADO és a DAO stb. Bár könnyű terjeszteni az Access-adatbázist azoknak a felhasználóknak, akiknek az Access már telepítve van a számítógépükre, nem olyan könnyű ellenőrizni, hogy az Access melyik verziója nyílik meg annak futtatásához.
előfordulhat, hogy egy PC-n az Access több verziója van telepítve. ACCDB vagy MDB fájl megnyitása közvetlenül elindítja az adott fájlkiterjesztéshez társított Access verziót (általában az utoljára megnyitott Access verziót).
ezenkívül az Access 2000 bevezetésekor az új MDB fájlformátum nem volt kompatibilis az Access 97 korábbi verziójával. Az adatbázis megnyitása az Access 2000-ben (vagy újabb) frissítheti az adatbázist az új formátumra, és megakadályozhatja a régi verzió felhasználóinak megnyitását, ami többfelhasználós környezetben problémát jelentett. Ez a probléma a 2000-es verzió óta nem ismétlődött meg.
a Total Access Startup programunk segít a szervezeteknek központilag kezelni és telepíteni a Microsoft Access adatbázisokat az egyes felhasználók asztalára, és szabályozni, hogy az Access melyik verzióját indítják el. Ez megkönnyíti az Access-alkalmazások gyorsbillentyűvel történő terjesztését, és az adatbázis legújabb verziója mindig telepítve van minden felhasználó gépére. Ezenkívül egyszerűvé teszi az alkalmazás frissítését az Access egyik verziójáról a másikra.
a Microsoft Access különböző verzióinak kezelésével vagy a Microsoft Access adatbázisok frissítéseinek terjesztésével kapcsolatos problémák nem oldódnak meg az SQL Serverre való áttelepítéssel, ha az adatbázis Access előlapját megtartja. Csak a Microsoft Access teljes cseréjével lehet kezelni. Ez megoldhatja a közvetlen problémát, de megakadályozza a felhasználókat abban, hogy munkájukat elvégezzék. Láttuk, hogy a szervezetek csak az alkalmazottak számára tiltják meg a Microsoft-hozzáférést, hogy rosszabb adatbázis-termékeket vásároljanak, mivel az adatbázis-probléma nem szűnt meg. A legtöbb szervezet számára nem praktikus professzionális fejlesztők segítségével létrehozni minden szükséges adatbázist, amikor a legtöbbet a végfelhasználók kezelhetik.
teljesítmény
a teljesítmény gyakori oka annak, hogy az emberek frissíteni akarják Microsoft Access-adatbázisukat SQL Server-re. Feltételezhető, hogy az SQL Server gyorsabban fog futni, mint egy Microsoft Access adatbázis. Végül is az SQL Server-t egy külön kiszolgáló kezeli, amely csak a kért rekordokat küldi el, és több CPU-t és gépet használhat hatalmas adatkészletek kezelésére.
a Microsoft Access fájlalapú fájlként elküldi a teljes adatbázist, táblát vagy indexet az ügyfél (PC) által feldolgozandó kéréstől függően.
bár ez adná a szélén, hogy a szerver megközelítés, azt találtuk, hogy a teljesítmény nem javult sok esetben. Íme néhány ok:
- sok Access adatbázis viszonylag kicsi (100 MB alatt). A jelenlegi hardverrel és hálózati kapcsolattal az átadott adatok mennyisége szinte azonnali, akár néhány rekord, akár az egész táblázat.
- az SQL Server extra munkát végez, amit az Access adatbázisok nem. Például az SQL Server képes fenntartani a tranzakciós naplót, és folyamatos karbantartást végez, amely növeli a költségeket. Láttuk csökken a teljesítmény, ha a kis adatbázisok upsized SQL Server.
- az SQL Server nagyon nagy adatbázisok kezelésére szolgál, jóval a 2 GB-os hozzáférési korláton túl. Nincs optimalizálva arra, amit apró adatbázisoknak tartana.
- a különböző csatolt táblázatforrásokból származó lekérdezések végrehajtása nem biztos, hogy előnyös az SQL Server-optimalizálás szempontjából, mivel a munkát továbbra is az Access végzi
- a Microsoft Access által az Access táblákhoz tárolt adatok gyorsítótárazása azért létezik, mert tudja, hogy az adatok megváltoztak-e. Az SQL Server-adatok esetében a memóriában történő gyorsítótárazás nem lehetséges, mert az adatok az utolsó kérés óta megváltoztak.
- egy rosszul megtervezett táblázatkészlet, lekérdezés vagy VBA kód lassan fog futni, függetlenül attól, hogy az adatok az Access vagy az SQL Server rendszerben vannak-e.
mielőtt teljesítmény okokból bővítené az SQL Servert, győződjön meg arról, hogy az Access-adatbázis optimalizálva van, hogy az az Accessben a lehető legjobban futjon. Az SQL Server nem oldja meg a komoly adatbázis-és lekérdezési tervezési problémákat. Ezek javítása az Access-ben valójában könnyebb, mint később az SQL Server-ben, így az erre fordított idő és erőfeszítés megmarad, ha később növeli a méretét.
annak érdekében, hogy a Microsoft Access adatbázisának ne legyenek komoly problémái, használja a Total Access Analyzer programot az adatbázis dokumentálásához és elemzéséhez. Több mint 300 típusú hibát, tervezési javaslatot és teljesítményproblémát észlel, amelyek segíthetnek az Access-adatbázis optimalizálásában.
viszonylag kis Microsoft Access-adatbázisok esetén ne méretezzen SQL Server-re kizárólag teljesítmény okokból. Az upsizing után csökkenhet a teljesítmény. Keresse meg a hozzáférési problémák optimalizálásának módjait, mielőtt befektetne az upsize-be. Előfordulhat, hogy a teljesítményproblémák nem kapcsolódnak az adattároláshoz.