Avatar billede mogw Nybegynder
29. april 2005 - 00:22 Der 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.

-mogw
Avatar billede dragonknight Juniormester
29. april 2005 - 00:32 #1
Tabel 1 laver du så den bare indeholder postnummer og by, for så kan du lave, så den selv finder bynavnet, når den bare får postnummer.
Avatar billede jkrons Professor
29. april 2005 - 00:33 #2
Hvis du ikke skal registrere andet end personlige informationer om medlemmerne, ser det vel ganske fornuftigt ud.
Avatar billede dragonknight Juniormester
29. april 2005 - 00:33 #3
Du skal selvfølgelig ikke have by med i tabel 3 i dette tilfælde.
Avatar billede dragonknight Juniormester
29. april 2005 - 00:34 #4
men bortset fra det, så ser det godt ud :-)
Avatar billede mogw Nybegynder
29. april 2005 - 00:35 #5
Det regnde jeg også med, det samme med tabel 2.

Hvad med tabel 3, skal jeg oprette et felt både for postnummer og by, eller finder den selv ud af det når man kæder dem sammen
Avatar billede dragonknight Juniormester
29. april 2005 - 00:36 #6
Er der kontigentbetaling som relaterer sig til medlemstype ?
Avatar billede dragonknight Juniormester
29. april 2005 - 00:36 #7
Du behøver ikke by
Avatar billede jkrons Professor
29. april 2005 - 00:36 #8
I tabel 3 skal du kun have Postnummer. Så kan du med en forespørgsel trække bynavnet ud fra tabel 1 efter behov.
Avatar billede mogw Nybegynder
29. april 2005 - 00:37 #9
Ups, det havde du allerede svaret på. i tabel 3 skal jeg vel så lave postnr som en opslag til tabel 1. Hvordan skal relationen mellem de to se ud?
Avatar billede dragonknight Juniormester
29. april 2005 - 00:37 #10
I tabel 3 har du postnummer, som så har relation til tabel 1, og så kommer by automatisk med.
Avatar billede jkrons Professor
29. april 2005 - 00:39 #11
Du kan godt lave tabel 3 med opslag i tabel 1, men generelt er det ikke verdens mest geniale løsning at lave en opslagstabel med mere end 1200 rækker.
Avatar billede dragonknight Juniormester
29. april 2005 - 00:39 #12
Postnummer i tabel 3 har relation til postnummer i tabel 1, og postnummer i tabel 1 er primary key.
Avatar billede mogw Nybegynder
29. april 2005 - 00:39 #13
>>Er der kontigentbetaling som relaterer sig til medlemstype ?

Ja, der er forskellig kontigent alt efter medlemstype
Avatar billede dragonknight Juniormester
29. april 2005 - 00:40 #14
At der er 1200 rækker betyder ikke så meget, når bare de er sorteret i nummerorden.
Avatar billede jkrons Professor
29. april 2005 - 00:41 #15
dragonknight-> Men der er s´gu langt at bladre, hvis du skal finde et postnummrer i opslagsrullelisten.
Avatar billede dragonknight Juniormester
29. april 2005 - 00:42 #16
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.
Avatar billede dragonknight Juniormester
29. april 2005 - 00:43 #17
Om det tager 1/10 sekund eller 1/100 sekund er uvæsentligt.
Avatar billede jkrons Professor
29. april 2005 - 00:44 #18
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.
Avatar billede dragonknight Juniormester
29. april 2005 - 00:44 #19
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.
Avatar billede jkrons Professor
29. april 2005 - 00:45 #20
Det kunne man selvfølgelig. Men det ændre ikke på, at man normalt vil kunne taste 4 cifre hurtigere end man kan slå op i en opslagstabel.
Avatar billede dragonknight Juniormester
29. april 2005 - 00:46 #21
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.
Avatar billede dragonknight Juniormester
29. april 2005 - 00:47 #22
Jeg tror du har misforstået mig.

Postnummer skal også være i tabel 3, men for ikke at skulle indtaste bynavn, så relaterer det til tabel 1, som også har postnummer, men også bynavn.
Avatar billede jkrons Professor
29. april 2005 - 00:48 #23
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.
Avatar billede mogw Nybegynder
29. april 2005 - 00:48 #24
Kunne man ikke gøre så man kan begge dele, taste hvis man kan nummeret, slå op hvs man er i tvilv. Jeg har en tabel med 590 postnumre.
Avatar billede dragonknight Juniormester
29. april 2005 - 00:48 #25
Er du med mogw ?
Avatar billede mogw Nybegynder
29. april 2005 - 00:50 #26
jaja, jeg er lige her
Avatar billede jkrons Professor
29. april 2005 - 00:50 #27
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 :-)
Avatar billede dragonknight Juniormester
29. april 2005 - 00:52 #28
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.
Avatar billede dragonknight Juniormester
29. april 2005 - 00:52 #29
Så må han finde ud af det.
Avatar billede jkrons Professor
29. april 2005 - 00:53 #30
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.
Avatar billede jkrons Professor
29. april 2005 - 00:54 #31
dragonknight-> Der er ingen der taler om at have byen i tabel 3. Bortset fra i mowq første indlæg.
Avatar billede mogw Nybegynder
29. april 2005 - 00:54 #32
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
Avatar billede mogw Nybegynder
29. april 2005 - 00:56 #33
jkrons >> den by jeg snakker om i første indlæg skal betragtes som stednavn, altså hvilken landsby eller andet stedbetegnelse vedkomne kommer fra
Avatar billede jkrons Professor
29. april 2005 - 00:59 #34
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.
Avatar billede dragonknight Juniormester
29. april 2005 - 00:59 #35
jeg har også arbejdet meget med relations databaser, og har også lavet flere medlemsdatabaser.

Jeg ville lave det således !

Tabel 1                Tabel 3                Tabel 2
                        MedlemsNummer (key)
                        ForNavn
                        EfterNavn
                        Adresse
Postnummer ------------ PostNummer       
ByNavn                  TelefonNummer
                        MobilNummer
                        E-Mail
                        MedlemsType-------------Medlemstype
                        Ja/Nej                  Kontingent

Hvor -------------- representerer en relation.
Avatar billede jkrons Professor
29. april 2005 - 01:01 #36
dragonknight-> Sådan ville jeg nok også lave den, med mindre et medlem kan have flere typer på en gang. Men det afhænger jo af foreningen :-)
Avatar billede mogw Nybegynder
29. april 2005 - 01:03 #37
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.
Avatar billede jkrons Professor
29. april 2005 - 01:05 #38
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.
Avatar billede dragonknight Juniormester
29. april 2005 - 01:06 #39
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.
Avatar billede dragonknight Juniormester
29. april 2005 - 01:11 #40
Til regnskab skal du bruge en seperat tabel, som har medlemsnummer som primary key, og den har så relation til medlemsnummer i tabel 3.

I den seperate tabel, lad ocs kalde den tabel 4, kan du så have:

Tabel 4
Medlemsnummer
KontingentSum
ErBetalt
GiroSendt
RykkerSendt

Ja kun fantasien sætter grænsen.
Avatar billede mogw Nybegynder
29. april 2005 - 01:11 #41
jkrons>> skal du felter med betalingsdato mm være i tabel 3, eller skal der laves en ny til det?

dragonknight>> det med at lave regnskab på hver enkelt medlem, er det noget som fylder meget/svært at lave??
Avatar billede jkrons Professor
29. april 2005 - 01:14 #42
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.
Avatar billede mogw Nybegynder
29. april 2005 - 01:14 #43
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
Avatar billede jkrons Professor
29. april 2005 - 01:14 #44
Du er velkommen :-)
Avatar billede dragonknight Juniormester
29. april 2005 - 01:19 #45
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.
Avatar billede dragonknight Juniormester
29. april 2005 - 01:19 #46
Ja, velbekomme  ;-)
Avatar billede jkrons Professor
29. april 2005 - 01:24 #47
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.
Avatar billede mogw Nybegynder
29. april 2005 - 01:27 #48
jkrons>> har ikke brug for at se om betalingsdatoen er overskredet, bare om der er betalt eller ej
Avatar billede jkrons Professor
29. april 2005 - 01:29 #49
Fint nok. Så kan du registrere det med et Ja/Nej felt.
Avatar billede dragonknight Juniormester
29. april 2005 - 01:35 #50
se her: 29/04-2005 01:11:51
Avatar billede mugs Novice
29. april 2005 - 05:48 #51
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.
Avatar billede jkrons Professor
29. april 2005 - 10:25 #52
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.
Avatar billede dragonknight Juniormester
29. april 2005 - 10:52 #53
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".
Avatar billede mugs Novice
29. april 2005 - 11:02 #54
Helt ening med Jer begge.
Avatar billede dragonknight Juniormester
02. maj 2005 - 21:00 #55
Hvordan går det her ? ? ?
Avatar billede mugs Novice
06. maj 2005 - 17:31 #56
Sidste kommentar fra spørgeren er 29/4. Lidt yderligere feedback vil være gavnlig for yderligere hjælp.
Avatar billede dragonknight Juniormester
22. maj 2005 - 12:34 #57
Er der lukketid, eller ? ?
Avatar billede mogw Nybegynder
27. maj 2005 - 23:13 #58
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.

-Mogw
Avatar billede dragonknight Juniormester
31. maj 2005 - 12:32 #59
Selvfølgelig vil vi det.

;-)
Avatar billede mogw Nybegynder
05. juni 2005 - 19:07 #60
Så mangler vi bare lige jkrons også
Avatar billede dragonknight Juniormester
11. juli 2005 - 12:33 #61
jkrons ? ?
Avatar billede Ny bruger Nybegynder

Din løsning...

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.

Loading billede Opret Preview
Kategori
Dyk ned i databasernes verden på et af vores praksisnære Access-kurser

Log ind eller opret profil

Hov!

For at kunne deltage på Computerworld Eksperten skal du være logget ind.

Det er heldigvis nemt at oprette en bruger: Det tager to minutter og du kan vælge at bruge enten e-mail, Facebook eller Google som login.

Du kan også logge ind via nedenstående tjenester