Vastus (25.01.2023 16:50): Iga töö jaoks on oma tööriistad. Töövahend pole universaalselt halb ega hea, vaid sellel on sobivad ja mittesobivad kasutusvaldkonnad. Ma pole nõus nendega, kes MS Accessi põlastavad ja selle peale nina kirtsutavad. Prototüüpide, üksikkasutajate andmebaaside ja väikeettevõtete andmebaaside loomiseks on see väga hea vahend. Saan aru, kui kõhklusi tekitab hind, suletud lähtekood või tootjafirma maine, kuid funktsionaalsuselt on see väga hea vahend. Lihtsalt "ilusate silmade" eest selles pingereas kõrgele kohale ei jõua (MS Access on seal esikümnes või selle lähedal).

Siin on näide artiklist, kus tuuakse välja MS Accessi puuduseid. Samas selles samas artiklis välja toodud alternatiivide juures tuuakse välja nende nõrgad küljed, mis näitavad nende alternatiivide nõrkuseid. Selle sama artikli kommentaaride osas on elav arutelu, kus ei olda autoriga nõus. Muuhulgas viidatakse seal 2019. aasta intervjuule MS Accessi programmijuhiga, kes kinnitab Microsofti jätkuvat pühendumust MS Accessi edasi arendada. Siin, siin ja siin on hiljutised arutelud selle kohta, kas "Access on surnud" (arutlejad on üldiselt seisukohal, et ei ole).

Nimetan järgnevalt mõningaid MS Accessi eeliseid konkurentide ees. MS Access on töölaua andmebaasisüsteem. Võrreldes "vanemate vendade/õdedega" - serveri andmebaasisüsteemidega (nt PostgreSQL, Oracle erinevad väljaanded, MySQL) - on sellel palju puudujääke. Kuid kas on ka eeliseid? Jah on. Üksiti võttes võivad tunduda väikesed asjad, kuid palju väikeseid asju annab kokku ühe suure.

• Tabeli veergude järjekorra muutmiseks tabelis tuleb tabeli disainivaates veergu sobivale kohale lohistada.
  
  • SQL tabelites on veerud vasakult paremale järjestatud. Igal veerul on järjekorranumber. Mõnes olukorras tuleb seda järjekorranumbrit teada. Paraku ei paku SQL  lauset tabeli veergude järjekorra muutmiseks või veeru lisamiseks konkreetsele positsioonile. Seega on teistes süsteemides enamasti lahenduseks tabeli kustutamine ja uuesti loomine.
• CHECK kitsendustes saab kasutada alampäringuid.
  
  • Võimaldab realiseerida deklaratiivsel viisil keerukate reeglite kontrolli. See tähendab, et süsteemile öeldakse, mida peab kontrollima, mitte kuidas seda teha. Näiteks PostgeSQL ja Oracle ei luba CHECK kitsendustes alampäringuid ning keerukamate reeglite andmebaasi tasemel jõustamiseks ei jää üle muud kui luua trigereid. Trigerites kirjeldatakse andmete kontrolli protseduur. Koodi on palju rohkem kui deklaratiivsete kitsenduste puhul ning lihtne on teha vigu. Muide, ka MS Accessis on võimalus sisuliselt luua trigereid - selleks tuleb luua andmemakrod.
• Attachment tüübi kasutamine veeru tüübina, mida saab määrata ainult läbi graafilise kasutajaliidese, võimaldab lihtsalt ja mugavalt realiseerida failide andmebaasis hoidmise.
  
  • Andmebaasirakenduse kaudu hallatavate failide (näiteks veebipoe kaupade pildid) hoidmine väljapool andmebaasi (andmebaasisüsteemi kontrolli alt väljas) on üks SQL disaini antimustritest - Assume You Must Use Files (Phantom Files) (Chapt 12).
• Tabeli disainivaates saab valideerimisreeglitega koos määrata valideerimisteksti. Seda näidatakse kasutajale kui tema andmemuudatus eksis selle reegli vastu. Niimoodi on võimalik kerge vaevaga määrata (loodetavasti head ja arusaadavad) veateated, mida kasutajale näidatakse.
  • Paraku ei pöörata veateadete heale kasutatavusele paljude programmide puhul piisavat tähelepanu.
• Päringute kujundaja (query designer) pakub ka võimalust andmete muutmise lausete (INSERT/UPDATE/DELETE) koostamiseks.
  • SELECT lausete graafilise kasutajaliidese abil koostamise võimalust pakutakse paljudes programmides, kuid andmete muutmise lausete sellise koostamise võimalusega polegi ma muudes programmides kokku puutunud.
• TOP predikaat, mida saab kasutada ka teistes Microsofti andmebaasisüsteemides, kuid mida ei kirjelda SQL standard, võimaldab mitmeid ülesandeid lihtsamalt lahendada. Näiteks - leia hotellid, milles on toimunud kõige rohkem reserveerimisi (selliseid hotelle võib olla rohkem kui üks).

SELECT TOP 1 hotelli_nr
FROM Reserveerimine
GROUP BY hotelli_nr
ORDER BY Count(*) DESC;

• Andmebaasisüsteemiga ühte programmi integreeritud andmebaasirakenduste loomise võimalus on hea näide väikese kodeerimise vajadusega arenduskeskkonnast (low code development environment).
  • See on IT süsteemide arenduse üks oluline tulevikusuund. IT on igal pool ja inimestel on vajadus/soov luua kiiresti endale kõige sobivamat tarkvara. Süsteemiarendus demokratiseerub, st võimalikult paljud peaksid seal saama kaasa lüüa.
  • Näiteks Oracle veebirakenduste kiirprogrammeerimise keskkonnas Apex andmebaasirakenduse loomise kasutajakogemus meenutab väga palju MS Accessi kasutamise kogemust. Vahe on selles, et Apexis on kogu arendusliides veebipõhine ja arenduse tulemusena valmib Oracle andmebaasi kasutav veebirakendus.
• Võimalus kasutada SQL lausetes parameetreid, mille väärtust küsitakse lõppkasutajalt või loetakse mõnelt ekraanivormilt.
• Andmebaasirakenduse mugavam muutmine.
  • Muutes tabeli/veeru nime muudetakse paljudel juhtudel automaatselt (siiski küll mitte alati) ka salvestatud SQL lauseid (queries) nii, et need arvestaksid uute nimedega. Paraku alampäringuid ei osata muuta.
  • Muutes tabeli/veeru nime muudetakse paljudel juhtudel automaatselt (siiski küll mitte alati) ka ekraanivorme nii, et need arvestaksid uute nimedega.  Muudetakse just selliseid vorme, mis on seotud tabelitega (bound forms), st mitte selliseid, kus andmete leidmine ja esitamine käib kasutaja kirjutatud VBA koodi kaudu.