Leden administratie

[hammie76]

Goedemorgen,

Voor onze club ben ik bezig met het opzetten van een ledenadministratie.
We hebben de volgende typen leden:
- Volwaardige leden (dit zijn gewone leden en fokkers)
- proefleden
- gezinsleden

Je kan alleen een proeflid worden wanneer je wordt aangemeld door een fokker. Dus een fokker moet bestaan voordat er een proeflid aangemaakt kan worden.
Bij de gezinsleden geldt dat er een volwaardig lid op het zelfde adres aangemeld moet zijn, anders mag je geen gezinslid worden.

Ik heb al een begin gemaakt met de relaties tussen de tabellen die ik denk nodig te hebben.
Bekijk bijlage Relaties voor Database1.pdf

Ik heb een aparte adres tabel gemaakt omdat je bij gezinsleden immers het adres kan hergebruiken.
nu kan ik een veld type lid opnemen met daarin volwaardig lid gezinslid proeflid en fokker, maar dan zie ik niet hoe je bovenstaande afhankelijkheden kan implementeren. Of moet ik juiste van meerdere tabellen gebruikmaken per type lid.

Ik hoop dat iemand mij op het juiste spoor kan zetten, want het goed opzetten van de database scheelt een hoop werk

Alvast bedankt.

Hammie

 

[gast0660]

Ik wil wel helpen om het in de juiste vorm te gieten. Zolang dat de fokkers geen broodfokkers van honden zijn.
Ik neem aan dat je al een (stuk) database hebt, eventjes de lege datbase posten, dat scheelt een hoop typwerk
Je kan me altijd contacteren op *knip*

Groetjes

 

[hammie76]

Wauw, dat is wel een hele snelle reactie.
Ten eerste dank je wel voor je aanbod en ik ga er zeker gebruik van maken.
Ik denk dat die broodfokkers niet eens een klanten administratie bijhouden.
Bij gevoegd heb ik de eerste opzet van de database.
Hij is gemaakt in Access 2010.

nogmaals bedankt.

Bekijk bijlage LEDENADMINISTRATIE.zip

 

[gast0660]

Ik ga het zaakje eens bekijken

groetjes

 

[OctaFish]

Een paar opmerkingen alvast:

Je kan alleen een proeflid worden wanneer je wordt aangemeld door een fokker. Dus een fokker moet bestaan voordat er een proeflid aangemaakt kan worden.

Als ik het goed begrijp mag iemand zich dus niet zelf aanmelden; het aanmelden moet gebeuren door een door jullie erkende fokker. Dat roept gelijk een vraag op: hoe geschiedt dat aanmelden? Telefonisch, aan de balie, per mail/brief? Het is belangrijk om het aanmeldproces goed beschreven te hebben, want in de db zelf is het lastig om het proces correct af te dwingen. Dat kan nog wel op formulieren, maar die zitten nog niet in je db .

Bij de gezinsleden geldt dat er een volwaardig lid op het zelfde adres aangemeld moet zijn, anders mag je geen gezinslid worden.

Je denkt hier nog vanuit je adressentabel (zie volgend punt). Is niet nodig; de vraag is natuurlijk ook: waarom zou je die eis stellen? Als het gaat om een familie lidmaatschap, dan is dat hooguit een administratieve regeling vermoed ik (aangepaste tarieven etc). Of een familielid daadwerkelijk op hetzelfde adres woont lijkt mij niet echt boeiend. En hoe ga je om met ingeschreven families (allemaal bij elkaar wonend) waarvan één lid na een jaar op zichzelf gaat wonen? En dat dan ook nog eens niet doorgeeft? Lijkt mij allemaal nauwelijks controleerbaar!

Ik heb een aparte adres tabel gemaakt omdat je bij gezinsleden immers het adres kan hergebruiken.

Dat nu is totaal niet nodig. In een CP tabel leg je alle details vast van een CP, dus ook zijn/haar adres. Normaal gesproken zal een CP op één adres wonen, en dan heb je daar meer dan genoeg aan. Zit je clientèle landelijk verspreid, denk dan aan een koppeling met een Postcodetabel. Je hoeft dan niet meer op te slaan dan PC + Huisnummer, want de rest haal je uit de Postcodetabel(len). Werk je lokaal, dan kun je de Postcodes waarin je werkt wel opnemen in de database. Met aparte tabellen voor Plaats, Straat en PC codes. Op basis van die tabellen kun je dan een adres samenstellen voor mailings. Bij elke nieuwe klant/lid die op een niet-geregistreerde postcode (dus onbekend adres) woont, vul je de tabellen aan met de nieuwe gegevens. Uiteindelijk krijg je dan adrestabellen die precies voldoen aan jouw wensen, en ook niet groter zijn dan nodig.

Of moet ik juiste van meerdere tabellen gebruikmaken per type lid.

Dat NOOIT!! Entiteiten (zoals leden) horen bij elkaar in één tabel. Hooguit geef je in zo'n tabel met keuzevelden of selectievakjes aan welke status een persoon heeft.

 

[gast0660]

Hoi,
@octafish,ocharme hammie76 heeft nu zeker een aanval van migraine, maar ja uw opmerkingen zijn natuurlijk terecht.
@hammie76, ik zou ook graag wat meer details van aanmelden (eerste vraag van octafish) weten op een (door)start te kunnen maken

greetz

 

[OctaFish]

Een database bouwen doe je pas nadat je een Functioneel Ontwerp hebt. De antwoorden op mijn vragen zouden dus zo uit het FO gelepeld kunnen worden, daar komt geen grammetje Paracetamol aan te pas . Al vermoed ik dat er geen FO is, want wie maakt dat nu wel? . Idem dito voor de tabellen(structuur); die is volslagen afhankelijk van dat FO. Maar laat TS maar over de brug komen met de antwoorden, dan kijken we weer verder.

 

[gast0660]

Hoi,
Ik heb de database ook eventjes vlug bekeken, ik kom x aantal tabellen tegen met contactID, je hebt wel al relaties aangemaakt maar geen enkele query, huisnummer maak je nummeriek, wat doe je dan met huisnummer B22 b.v.? geen enkel invulformulier etc. Eventjes een iets duiderlijker uitleg posten (tekstbestandje).

 

[OctaFish]

Huisnummers hoeven niet numeriek te zijn, maar dat mag natuurlijk best. Zeker als je ook een veld [Toevoeging Huisnummer] hebt voor de aanvullende tekens zoals letters. Ik zou het exact hetzelfde doen. Queries heb je pas nodig als je ze nodig hebt . De tabellenstructuur deugt in mijn ogen ook niet echt; alle CP gegevens horen bij elkaar, zoals ook alle ledengegevens bij elkaar in één tabel horen. Maar dat had ik al aangegeven. Dat TS nog geen formulieren heeft vind ik eigenlijk wel prima, want zolang de structuur niet goed is, moet je verder nog nergens wat aan doen. Eerst het fundament in orde, dan pas de tweede verdieping bouwen. En de eerste, en de begane grond...

Maar Hammie is denk ik inderdaad geschrokken, want erg stil

 

[gast0660]

Hoi octafish, mijn laaste postje waren een paar kronkeltjes van mij om Hammie op het juist pad (op zijn Vlaams: wegeltje, , ik ben een Vloaminck te helpen. Tenslotte is het helpmij, maar ja hij is verdacht stil,en zou je nog moeten bedanken voor een vorig postje (weet niet direct meer welke) maar heb de code wel opgeslagen in mijn persoonlijke bib
octafish met stip!! :thumb: Ik ben jammer genoeg thuis tot het einde van het jaar door een burn out dus ik heb vrij veel vrije tijd en ik wil gewoon mensen helpen. Mischien is het niet gepast,en ik wil niemand beledigen (alles moet geleerd worden) maar ik heb het gevoel dat Hammie zijn of haar kennis van Access eerder beperkt is. Ik wil nog altijd hammie verder te helpen, mits de nodige feedback, achthoekege vis ,ik twijfel niet aan uw kennis van access:d

 

[mastermindzh]

@gast0660,

Ik heb het e-mail van u uit de post gehaald.
Helpen doen we via het forum Daar heeft iedereen wat aan. :thumb:

@ts, ik ben het niet geheel eens met alle punten van bovenstaande heren.
2 Adressen komt naar mijn ervaring veel vaker door dan initieel verwacht. Ik zou dus de adresgegevens wel apart houden.

De manier waarop je dat het beste kan doen is zoals octafish al aangaf een koppeltabel.
Hieronder voorgedaan(in mysql maar het principe is hetzelfde)

[smallimg]http://i.imgur.com/wLHHbEb.png[/smallimg]



Ditzelfde principe zou ik voor rollen toevoegen, op die manier kan 1 lid meerdere rollen hebben. (bijv. gezinslid + fokker).
Deze wijzigingen hebben niet erg veel overhead en maken je systeem een stuk robuuster en uitbreidbaarder in de toekomst.

Voor de rest met OctaFish eens hoor, eerst het ontwerp dan de db opzetten

 

[OctaFish]

Koppeltabellen zijn prima op het moment dat één tupel (een persoon in dit geval) meerdere objecten heeft van een andere entiteit (zoals wellicht meerdere adressen). Heb je altijd maar één adres, dan is die constructie zinloos. Wat je dan nog wel ziet is dat men in de tabel de velden doubleert ([Adres 1], [Adres 2] etc) maar dat moet ten sterkste worden afgeraden: in dat geval is een koppeltabel echt beter.
De laatste opmerking van mastermind, ja, daar ben ik het dan toch weer niet mee eens. Zelf zou ik het waarschijnlijk wél doen (aparte tabel) maar je kunt tegenwoordig voor dit soort gegevens best een veld maken dat meerdere waarden kan hebben. Die vul je dan in de tabel middels een keuzelijst met aankruisvakjes. Snel en simpel, en evengoed toch nog prima in enkelvoudige entiteiten te splitsen zodat je wel degelijk genormaliseerde queries kunt maken. Enige eis bij zo'n veld: het moet gegevens bevatten die maar één attribuut hebben. Dus een keuzelijst met waarden als Gezinslid, Fokker etc kan prima met zo'n keuzelijst. Een adressenbestand dus niet, want een adres heeft teveel attributen (Straatnaam, Postcode, Huisnummer etc).