Updaten of een nieuwe applicatie ontwikkelen?
Een ontwikkelaar kan vele uren verslijten aan het onderhouden en/of updaten van een applicatie. Maar of dat ook de beste investering voor uw organisatie is, is nog maar de vraag...
Indien u dat wenst, zullen wij u een voorstel doen om uw huidige applicatie te analyseren zodat u inzicht krijgt waarin u investeert.
De werkwijze is van doorslaggevende aard
Access applicaties worden vaak gebouwd door handige medewerkers of door iemand die zich als 'Access specialist' heeft voorgedaan. Vaak wordt stukje bij stukje aangebouwd om weer een deel van de administratie 'op orde' te krijgen met als gevolg een onoverzichtelijke en rommelige applicatie. We kunnen er boeken over volschrijven...
Vanwege onvoldoende kennis kunnen lange tijd onvolkomenheden onopgemerkt blijven waardoor de ene fout op de andere gestapeld wordt. Dit scenario, waarvan men kan zeggen dat er uiteindelijk veel schade is aangericht, is een alom bekend fenomeen.
Wanneer u een bestaande Access applicatie wilt laten updaten, is het dus de vraag of dat dat de meest wijze en goedkoopste weg is. Als de applicatie echt goed is gebouwd, dan is een update zo doorgevoerd, natuurlijk afhankelijk van wat er gedaan moet worden. Maar wanneer blijkt dat de kennis en de technieken van de bouwer te gering zijn geweest, wordt het volledig corrigeren van onvolkomenheden een tijdrovend werk.
Daarentegen heeft een echte Access specialist een dusdanige werkwijze ontwikkeld waarop hij snel en trefzeker professionele Access applicaties kan maken. Die omstandigheid is al snel van doorslaggevende aard in wat de meest verstandige keuze is. Want een nauwgezette en gestructureerde manier van werken met een jarenlange ervaring achter de rug, levert immers tijdwinst en betere applicaties op.
Onze uitgangsbasis is om kwalitatief werk te leveren. Natuurlijk bent u degene die bepaald tot in hoeverre een bestaande applicatie geoptimaliseerd moet worden.
Analyse van de bestaande applicatie
Indien u wenst, zullen wij u een voorstel doen om uw huidige database te analyseren. Hierdoor krijgt u inzicht in de huidige toestand en krijgt u inzicht waarin u investeert. U kunt de huidige applicatie naar gelieve gedeeltelijk of volledig laten optimaliseren. Het is helemaal aan u.
Hierna zullen we de belangrijkste factoren bespreken waar tijdens de analyse op zal worden gelet. Wij zullen u steeds vakkundig adviseren over wat te doen. De keuze is uiteraard altijd aan u.
Relaties tussen tabellen
Wanneer relaties tussen tabellen niet of niet correct zijn ingesteld, heeft dat zeer ernstige gevolgen. Bijvoorbeeld:
- Het ophalen van groepen records duurt lang.
- Gerelateerde records in secundaire tabellen blijven in de database bestaan terwijl dat niet de bedoeling is.
- Gerelateerde gegevens in een secundaire tabel worden niet bijgewerkt wanneer in een primaire tabel de primaire sleutel wordt gewijzigd. Gevolg is dat er geen match meer is van records waardoor de data niet meer opgemerkt wordt.
Dit is een zeer onbetrouwbare database. Het alsnog instellen van relaties kan tot problemen leiden omdat gerelateerde tabellen dezelfde waarde moeten bevatten. Ook wanneer gerelateerde sleutels niet zijn bijgewerkt en er dus geen match meer is tussen records in gerelateerde tabellen, is het zoeken naar spelden in een hooiberg (omdat de sleutel verbroken is zal dat allemaal handmatig moeten). Hoe ernstig de zaak is, hangt o.a. af van het aantal tabellen waarvan de relaties niet of niet correct zijn ingesteld en hoeveel records zich daar in bevinden die niet meer matchen.
Het alsnog instellen van relaties kan ook leiden tot een wijziging in de tabellen doordat er velden moeten worden toegevoegd of gewijzigd. Dat kan weer gevolgen hebben voor bestaande query's, voor programmacode, voor het algehele ontwerp van formulieren en rapporten.
Het oplossen van dit probleem kan leiden tot te hoge kosten.
Normalisatie van de database
Normalisatie houd o.a. in dat informatie niet dubbel wordt geregistreerd, dat er geen onnodige velden in een tabel zijn opgenomen en dat er per record nauwelijks velden zijn die niet van toepassing zijn.
In een slecht genormaliseerde database doet zich bijvoorbeeld de volgende situatie voor. Stel, er is een tabel Klanten met klantgegevens. Maar behalve de klantgegevens, zijn er ook nog 6 velden in deze tabel opgenomen om feedback van deze klanten te kunnen registreren. Velden zoals DatumIngekomenFeedback, TypeFeedback, FeedBackOmschrijving, AangeverFeedBack, FeedbackStatus, BehandeldDoor. Gezien het feit dat op voorhand vastgesteld kan worden dat slechts een deel van het totaal aantal klanten feedback zal geven, is dit een verkeerde keuze. Daardoor zullen er veel velden zijn die leeg zijn en, afhankelijk van het gegevenstype, geheugen vergen. De velden voor de feedback zijn voor een groot aantal records in de tabel Klanten niet van toepassing. Voor de goede gang van zaken had er daarom een aparte tabel moeten worden gemaakt waarin de feedback informatie wordt opgeslagen voor die klanten die wel feedback geven.
Een niet goed genormaliseerde database werkt, afhankelijk van de hoeveelheid gegevens en het netwerk, mogelijk traag. De indeling is vaak dusdanig onlogisch, dat doorbouwen op een onoverzichtelijke database tot problemen leidt die steeds groter worden. Afgezien van het feit dat een slecht genormaliseerde database onnodig geheugen vergt, moet het ontwerp worden herzien. Dat kan weer gevolgen hebben voor bestaande query's, voor programmacode, voor het algehele ontwerp van formulieren en rapporten.
Het oplossen van dit probleem kan leiden tot te hoge kosten.
Het correct afvangen van de data invoer
Formulieren zijn de beste objecten om de data in te voeren omdat de invoer dan met programmacode kan worden gecontroleerd. Het niveau van afvangmogelijkheden met programmacode is vele male hoger dan dat wanneer velden worden gecontroleerd op tabelniveau (d.w.z. dat de controle door beperkte en statische mogelijkheden in de veldeigenschappen in de tabel kan worden gestuurd). Aan tabellen en query's zijn namelijk geen code modules gekoppeld en daarom is men aangewezen op de beperkte afvangmethode indien de invoer via een query of een tabel gebeurt.
Het oplossen van dit probleem hoeft geen hoge kosten met zich mee te brengen.
Verwijderen van records
Gebruikers moeten beschermd worden voor het ongeoorloofd verwijderen van records, en wel voor twee belangrijke redenen:
- Dat ze niet steeds gedwongen zijn na te moeten denken of het wel of niet geoorloofd is.
- Dat er geen records onbedoeld en ongeoorloofd worden verwijderd.
Wanneer relaties tussen tabellen correct zijn ingesteld, kan Access dit voor een deel sturen, maar dat is zeker niet afdoende om bovenstaande twee punten 100% zeker te stellen.
Het oplossen van dit probleem hoeft geen hoge kosten met zich mee te brengen.
Prestatie
Hoewel de prestatie erg van de normalisering afhangt, kan de aanwezige programmacode ook verantwoordelijk worden gehouden voor een trage werking. Het gaat erom hoe de code geschreven is en/of gegevenstypen correct gedeclareerd zijn. Een variabele (een aanduiding waar een waarde in kan worden opgeslagen) kan als een bepaald gegevenstype worden gedeclareerd. Er zijn gegevenstypen de veel of weinig geheugen vergen. Wanneer aan een variabele geen gegevenstype is toegewezen, maakt Access er automatisch een type Variant van. Dit type kan voor elk soort gegeven worden gebruikt maar vergt daarom dan ook het meeste geheugen.
Wanneer voor variabelen geen gegevenstype is gedeclareerd, kan er vanuit worden gegaan dat de overige programmacode eveneens niet op professionele manier is geschreven.
Het oplossen van dit probleem kan leiden tot te hoge kosten.
Onderhoudsvriendelijk
Wanneer in de applicatie geen gestructureerd systeem van werken te bespeuren is, wanneer er geen gebruik wordt gemaakt van 're-useable code', hier zus werken en daar weer zo, dan is dat geen gunstige zaak. Wij noemen dat 'spaghetti programmeurs' (een bij elkaar geraapt zooitje).
Wat een applicatie vooral niet onderhoudsvriendelijk maakt is, wanneer er veel statische objecten zijn zoals query's, macro's en rapporten. Op de pagina Geen onderhoudskosten voor een Office Programs Access applicatie kunt u er uitgebreid over lezen.
Het oplossen van dit probleem kan leiden tot te hoge kosten.
Gebruiksvriendelijk
Wanneer de gebruiksvriendelijkheid te wensen over laat, gaat dit ten kosten van de motivatie van de gebruikers en kost het werken met de applicatie tijd en dus geld.
Het oplossen van dit probleem is sterk afhankelijk tot in hoeverre het gebruiksgemak gewenst is en hoe de applicatie gestuurd wordt.
Tot slot
Tot slot nog enkele zaken die de uiteindelijke keuze van het beleid bepalen:
- De combinatie van bovenstaande factoren.
- De mate waarin er onvolkomenheden zijn.
- Hoe bedrijfskritisch/belangrijk de applicatie is.
- De hoeveelheid nieuwe functionaliteit die u in de huidige applicatie wilt laten aanbrengen. Wilt u slechts een beperkte update en de rest functioneert naar behoren of naar uw tevredenheid, dan kunt u het beter uitsluitend bij de gewenste update houden.
- Misschien is het een flinke tijd geleden dat de huidige applicatie is opgezet en zijn de bedrijfsprocessen veranderd. Dan kan het zinvol zijn te overwegen om een geheel nieuw ontwerp te maken.
- Tot in hoeverre u zelf de onvolkomenheden accepteert.
- Wat het verschil is tussen de kosten van het gedeeltelijk of volledig optimaliseren inclusief de nieuwe functionaliteit, en het geheel opnieuw ontwikkelen van de applicatie.
