[ACCESS] duwtje in de goede richting aub :) ?

[Verwijderd]

Als ik in de nabije toekomst een informatiesysteem wil opzetten die de onderlinge (regelmatig veranderende) relaties tussen en groot aantal entiteiten moet kunnen weergeven hoe kan ik dat het beste gaan aanpakken dan? Ik kan wel zomaar aan de slag gaan met Access maar ik wil niet op een doodlopende weg terecht komen.

Een paar dingen die een rol spelen:
er moet terug in de tijd uitgezocht kunnen worden welke verbanden er zijn geweest dus ik neem aan dat er een soort history tabel aangemaakt moet worden?

Er zijn ook veel jaarlijks terugkomende events (apk keuringen en verlopende vergunningen etc) die bij sommige entiteiten horen die eigenlijk een "alarmpje" moeten geven.

Kan iemand globaal (of specifiek ) zeggen hoe ik dit kan aanpakken en of het uberhaupt wel te doen is aangezien ik tot nu toe pas een beetje met access kan klungelen.
Ook vraag ik me af of ik nog op problemen kan stuiten bij het ontwikkelen van dit systeem wanneer er 3 a 4 personen mee moeten gaan werken op een (momenteel) peer-to-peer netwerkje (win98 en w2k)

[Creepy]

Hmm.. je kan alleen een "beetje" met access rommelen?
Weet je wat normaliseren is? Zo nee, dan zou ik hier niet eens aan gaan beginnen... of laat je DB ontwerp door iemand anders doen.

ACCESS werkt opzich prima... ik weet alleen niet hoe ACCESS omgaat met record locking... en dat heb je toch echt wel nodig als je met 3/4 man tegelijk in 1 DB gaat zitten bewerken. Zolang het alleen LEZEN van de db is kan access het prima aan..

En wat betreft history.. datum veld toevoegen en NOOIT record verwijderen.. heb je je history.. mochten de tabellen ERG groot gaan worden ACCESS dumpen en een fatsoenlijke SQL server aanschaffen.. maar zoals ik dat nu lees gaat dit niet zo snel gebeureb (3/4 clients? goed te doen in ACCESS)

Ik weet toevallig 1 DB van een website (een GROTE website!!) die geheel op ACCESS draait. Maar de acties op de database zijn 99% lezen..

[Verwijderd]

Het is niet per se een probleem als er maar 1 client tegelijk kan bewerken.

Tot nu toe ben ik niet verder gekomen dan een paar tabelletjes maken met relaties en wat query's.
Een aantal lessen op HEO gehad.

Waar had dat normaliseren mee te maken ?

[Creepy]

OM een goed datamodel te krijgen (je tabelletjes en je relaties) moet je dus weten welke gegevens je allemaal op wilt slaan. Deze gegevens moet je gaan "normaliseren" (oftewel netjes ordenen zodat de tabellen en onderlinge relaties logisch/netjes in elkaar zitten).

Als je database ontwerp een "zooitje" is, wordt je applicatie over het algemeen ook een lichtelijkt "zooitje" en dat is dus weer niet goed voor de onderhoudbaarheid en snelheid van de applicatie. En probeer in een DB die een zooitje is, en zonder documentatie maar eens wijs te worden uit diezelfde database enige tijd later... dat gaat als je dat zelf doet al moeilijk.. laat staan als een ander dit moet gaan bekijken.. helaas zelf al slechte ervaringen mee

[Banpei]

Waar had dat normaliseren mee te maken ?

Dat je je database niet verwart met excel alles in een tabel gooit...

[Verwijderd]

Koop even op de HEAO een diktaatje dat normaliseren behandeld... Ben je gelijk klaar.

[Verwijderd]

Nee dat begrijp ik wel, dat heeft met entiteiten en attributen te maken. Een tabel voor een werknemer (unieke sleutel kiezen/creeren) met verschillende kenmerken + tabel met gegevens over de auto waar hij mee rijdt en daar een n/m op n/m relatie tussen creeren. Relationeel model toch?

Dus in grote lijnen
- wat wil ik weten en bijhouden, welke relaties
- tabellen maken
- relationeel model
- query's om de informatie er uit te krijgen
- het geheel gebruiksvriendelijker maken mbv van forms (zowel voor uitvoeren van query's als het vullen van de tabellen)
- uitbreiden, aanpassen en optimaliseren van systeem?

En als dit geheel redelijk uit de verf komt kan ik me gaan verdiepen in een manier om de wijzigingen (persoon gaat met andere auto rijden of auto is totall loss) bij te houden en daar query's op uit te voeren?
Ik wil bijvoorbeeld weten wie er op een bepaalde datum met een auto reed want er is een bekeuring binnen

[Verwijderd]

Minimale basis voor een goed systeem:

- Brainstorm welke gegevens je allemaal wilt opslaan.
- Normaliseer die gegevens (Voila de tabellen)
- Maak een ERD (Entiteit Relatie Diagram)
ERD = Grafische weergave van de Tabellen, met hun onderlingen relaties (1 op n, n op m, etc)

Als het kan...Laat het ERD ook door iemand anders bekijken, komt vaak wel iets naar voren wat misschien beter c.q. handiger is.

- Creer de tabellen in je Acces
- Leg de juiste relaties

Ik weet niet wat je programmeer ervaringen zijn, maar als die niet al te best zijn en je wilt toch wat leuks maken met niet al te veel inspanning...verdiep je dan een beetje in VBA.

Suc6 ermee

[Verwijderd]

Ik wens je veel suc6! je begint namelijk meteen met een groot systeem terwijl ik uit de texten opmaak dat je verder nog geen ervaring hebt. veel kans dus dat het zo misgaat.

Misschien slim idee om eerst een kleiner oefen project te pakken. Daar leer je van je fouten dan en dan pas beginnen aan het "echte" werk..