29. april 2005 - 00:22Der er
60 kommentarer og 1 løsning
Hjælp til opbygning af medlemsdatabase
Hej
Jeg skal for en forening lave et medlemskartotek, men jeg må indrømme at mit kendskab til access gør at jeg ikke helt ved hvordan jeg skal gribe det an. Jeg kan sagtens finde ud af at lave tabeller, forespørgelser og raporter. Men jeg mangler ligesom lidt baggrund i hvordan man skal bygge en database op, altså hvor mange tabeller, hvordan skal de kædes sammen.
Det er database som kommer til at ligge på min egen maskine, så der er kun 1 bruger.
Felter som jeg skal have med i databasen. medlemsnr, fornavn, efternavn, adresse, by, postnr, tlfnr, mobilnr, e-mail, medlemstype, et par ja/nej felter.
Jeg ville selv bygge det op med 3 tabeller
tabel1 = postnumre (til opslag af postnumre) tabel2 = medlemstype (til defination af medlemmer) tabel3 = medlemmer (alt det sidste)
Hvordan ser det ud i jeres øjne, er der noget jeg skal være opmærksom på, eller noget jeg har glemt???
Jeg er ikke ude efter en færdig løsning, men bare en del hjælp til at få det bikset sammen.
Så ville jeg i tabel 2 sætte kontingent ind, og på samme måde som med postnummer, så har tabel 3 medlemstype relation til tabel 2 medlemstype, og hvor medlemstype i tabel 2 er primary key.
Det handler om, at bruger skal finde postnummer 8362 i en liste, der starter med 1000. Det tager nok mere end 1/10 sekund. Jeg vil påstå at man kan taste 8362 hurtigere end man kan finde det ved opslag.
Med 1200 postnumre, forudsætter du også, at alle postnumre er i tabellen. Hvis det nu er et begrænset geografisk område, som medlemmerne bor i, så kunne man jo nøjes med de numre.
Man sparer jo indtastningen af bynavn når man har det på den mpde jeg skitserer, og det opvejer så rigelig den ekstra tid det tager at finde et postnummer blandt 1200.
Nu svarede jeg på moqw's indlæg fra 00:37:16, og det handlede om, hvorvidt han skulle lave et opslagsfelt i tabel 3, så når han skal indtaste postnumre for medlemmerne, i stedet laver et opslag. Selv om du taster postnumrene i tabel 3, vil du jo stadig finde bynavnet automatisk.
mowq-> Det kan man godt. Men i almindelighed vil du vel have adresseinformationerne fra de medlemmer, der melder sig ind. Jeg har arbejdet med, og lavet medlemsdtabaser i mange år, og har aldrig oplevet, at et medlem ikke selv vidste, hvilket postnummer vedkommende bor i :-)
Sammenhængen mellem postnummer er unik, og det betyder, at der til 1 postnummer kun findes 1 by, og omvendt, derfor er det idioti, at have både postnummer og by i tabel 3.
Når man har en unik sammenhæng, så har man kun den ene enhed i en tabel, og lader så den relatere til en anden tabel, hvor man har begge enheder.
Den smarteste mpde er nok at lave en formular til dine indtastninger, så kan du lave et tekstfelt til postnummeret og en komboboks til bynavnet. det vil give dig mulighed for at taste et postnummer, og så funder den byen. Eller du kan vælge en by, og så finder den postnummeret.
nu er det en gammel forening hvor at bestyrelsen er den samme som har siddet i de sidste mange år, og alting kører på hukommelsen. Så når man får af vide at der er en der er flyttet får jeg som regel bare adressen og nærmeste større by, så skal jeg selv finde postnummeret til denne by
mowq-> Fint nok. Så er det også rigt at have informationen i tabel 3. Men den by, der tilhører postnummeret skal kun være i tabel 1.
Men hvis der er kontingenter mm. skal du så ikke kunne udskrive indbetalingskort/fakturaer. kontrollere om der bliver betalt, udsende eventuelle rykkere osv. For så kræver det nok flere felter i din database. Og evt. også flere tabeller.
jkrons >> som det ser ud nu bruger vi fortrykte girokort, hvor folk selv udfylder de felter som er nødvendigt, men det kunne godt om et par år blive nødvendigt at kunne lave girokort til den tid.
jo, jeg skal jo kunne kontrollere om hvornår der bliver betalt(skal jeg selv indtaste), kunne udskrive rykkere.
mowq-> Så er du også nødt til at have felter til indbetalt beløb, betalingsdato, evt. kontrol for om rykkere er udskrevet mm. Hvis I påligner rykkergebyr, skal der også være felt et til det.
Med ganske lidt Visual Basic programmering og koblet til Crystal Report, så kan du skrive medlemslister, udskrive girokort. Med lidt udvidelse af databasen, kan du også lave regnskab på det enkelte medlem. Skyldes der eller er der betalt, og skal der sendes rykkere.
Du kan gøre som dragonknigt beskriver, men du kan også have informationen i Tabel 3. Når du bruger medlmsnummer som PK i begge tabeller, skaber du en 1:1 relation. Og så kan du vælge at undlade opdelingen. Måske er det mest overskueligt at opdele, til gengæld mister du en anelse i performance, men nok ikke så meget, så du vil registrere det.
jeg bliver nødt til at kravle til køjs nu, skal køre hjemmefra kl. 05.45, vil gerne lige have lidt søvn inden. Men jeg vender tilbage, i morgen aften. I skal indtil videre have mange tak. Der er flere ting i det her end jeg lige havde regnet med
Moqw Betalingsdato er jo noget alle medlemmer har, og givervis den samme, derfor er det forkert, at have det som et felt i tabel 3, hvor der så ved alle medlemmer i dette felt vil stå det samme.
dragonknihgt-> Omkring betalingsdag, skal der vel skelnes mellem den dag, der skal betales, og den dag, der bliver betalt. Den sidste er jo ikke nødvendigvis den samme for alel medlemmer, og det behøver den første heller ikke at være. I den forening, hvor jeg er ansvarlig for medlemsregistreringen er betalingsdato fx 14 dage efter indmeldelesdato, så den varier ret meget, da medlemmerne løbende indmelder sig i foreningen. Og et eller andet sted skal den jo registreres, hvis databasen skal kunne se, om datoen er overskredet.
dragonknight's kommentar 01:11;51. Vedr en kontingentsum skal I tage i betragtning, at hvis kontingentet i år er f.eks 200 Kr vil dette blive skrevet i feltet kontingentsum. vis kontingentet så bliver forhøjet til næste år, vil det påvirke kontingentsummen også for i år da der er relationer mellem denne tabel og andre.
Hvis den samlede kontingentindbetaling skal opsamles for hvert enkelt medlem, vil jeg foreslå, at der ikke oprettes relationer til denne tabel.
mogw > Du har feltet e-mail med i dit indledende spørgsmål. Må jeg foreslå dig, at dui laver en funktion, så du kan sende e-mail til et medlem eller alle direkte fra din database. Jeg har skrevet en artikel om emnet.
mugs-> Som du er inde på, er der mange ting, som moqw skal være opmærksom på, når han designer sin database. Ting som er svære at hjælpe med, da vi ikke kender hans forening, og de behov den har. Databasedesignet bør jo altid afspejle de processer, som databasen skal understøtte. Og disse kan være meget forskellige fra forening til forening.
Det er også derfor at så mange af de standardiserede medlemssystemer, man kan købe, spiller fallit i konkrete situationer. Altså fordi de ikke afspejler den enkelte forenings måde at gøre tingene på :-)
Jeg sidder fx med to medlemsdatabaser, hvor kontingentdelen er strikket vidt forskelligt sammen - fordi de to foreninger bruger to vidt forskellige måder i deres kontingentopkrævning.
Kontingentsum var nu ment som et sted hvor der står hvad vedkommende skylder i kontingent, så benævnelsen Sum er nok lidt misvisende.
Tabel 4 skrev jeg lidt hurtig, og er ment som et eksempel. Den var påtænkt at skulle anvendes til at holde styr på hvem der har betalt, og så kan den bruges til at skrive girokort.
Det er rigtig jkrons som du skriver "Databasedesignet bør jo altid afspejle de processer, som databasen skal understøtte.", så derfor er det essentielt, at moqw ved helt nøjagtig hvad han vil have ud af den, før først da kan der gives et kvalificeret svar på, hvordan den skal "strikkes sammen".
Dragonknigt og jkrons smider i lige et svar, jeg kan vist ikke trække den længere. Beklager at der ikke er sket noget her i lang tid, men mit arbejde har taget al min tid i den sidste måned.
Jeg vender tilbage når jeg får lidt bedre tid. Håber i stadig vil hjælpe mig til den tid.
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
