Generelle kundedatabase spørgsmål

1. Skelne mellem hvad?

2. Lad være at skelne mellem afdelinger og underafdelinger, men behandl hver især som en kunde. Tildel derefter hver kunde et kundenr, som bliver tabellens primære nøgle. CVR bør herefter indekseret, men tillad dubletter.

Kunder er vel emner indtil de har købt, så antal ordrer > 0 lyder som en god idé, med mindre du sletter gamle ordrer erfterhånden. I så fald vil den anden løsning nok være bedre, da du ellers kan komme til at betragte en gammel kunde som et emne.

Den rigtige løsning i designet bør altid afspejle den konkrete situation.

1.
Skelne mellem om Firmaet er en kunde eller - endnu - blot et emne.

2.
Ja ok.. Jeg kan ikke heeelt bruge det, og dog.
Lad os sige vi har en ny kunde Istedhøj Kommune. Den har 50 underafdelinger (skoler, værksteder osv). Jeg vil gerne have det sådan, at underafdelingen kan hæftes uden videre til kommunen. Det kan de vel ikke hvis de står i samme tabel?
Altså:
1. Nogen gange skal en skole (i en kommune) selv betale for noget, andre gange skal kommunen betale for skolen.
Uanset hvem der betaler, så vil jeg gerne have overblik over, hvilke underafdelinger der hører til firmaet/kunden..

Nu skriver jeg, "hvad jeg gerne vil have".. Det er ikke sikkert at det er det kloge, så du/I må meget gerne kommentere hvordan jeg bør strukturere oplysningerne i KDBen..

Men tak for svaret Mugs

Ordrer > 0 er vel sådan set iorden, men så skal man tælle ordrerne først. og derefter indsætte et kriterie >0. Jeg vil foretrække et numerisk felt i tabellen der markerer om der er tale om et kundeemne eller en kunde. dette numeriske felt kan så bruges som lagring i en gruppeboks i en formular.

En anden nok så vigtig ting er det forhold om der skal være nogen historik i KDB. Hvis du f.eks skal gemme ordrerne for f.eks at beregne en rabat pr. år, hvis kunden har købt så og så meget, skal du tænke på at oprette en speviel tabel til allerede effektuerede ordrer. Hvis f.eks prisen stiger, vil du ændre prisen på gamle ordrer, hvis disse ikke er adskilt fra de ordrer du opretter idag.

M.ht. underafdelinger kan du lave en speciel tabel til disse, og hæfte en værdi på dem, der refererer til kunden.

Ja det komplicerer sig lynhurtigt.
Nu de to tabeller allerede blevet til 6-7 stykker :o)
/hekla

hekla -> det er jo een af de fascinerende ting ved at arbejde med emnet. Jeg er utallige gange startet med en lille db, fordi en kollega har spurgt:

Kan du ikke lige? Ikke noget særligt, men bare lige!

Og før man ved af det, så sidder man med notater til op over begge ører. Blot  min kommentar med en særskilt tabel til effektuerede ordrer, har garanteret sat spørgeren grå hår i hovedet. Men det er da den rigtige begyndelse, der er gjort her ved at spørge. For kan man undgå at lave bare en brøkdel af de fejl andre har lavet, så er der sparet megen tid.

mugs> Du har fuldstændig ret i at starten af en ny database, nemlig strukturen, er det, der kan koste allermest tid, hvis man sjusker, men det er altså også det sjoveste, når man får øje på, hvordan det skal gøres.

Jeg kender godt det med at påtage sig en lillbitte opgave. Jeg startede min Access karriere med at der var en i Basketklubben, der spurgte om ikke jeg lige kunne sætte lidt system på det Excell regneark, hvor de havde deres medlemsliste. Det tog mig et halvt år!

torejessen> Undskyld jeg misbruger dit spørgsmål.

hekla > Jeg tror vi har diskuteret dette emne før. Når dette spørgsmål dukker op, er dette mange gange mit første råd:

Sluk for computeren. Tag papir og blyant og "tegn" din db.

På den måde bliver man ikke lokket til at prøve, for når man prøver, bliver man alt for let lokket på afveje, og før man ved af det, er der gået flere timer med noget, der i bedste fald blot kunne være gjort bedre.

Hvis alle i højere grad ville gøre en indsats for at tænke over konstruktionen, ville megen tid være sparet og mange ærgelser være undgået.

Godmorgen :-)

Tak for hjælpen.
Heldigvis får jeg ikke grå har af at tænke på en "effektueret" ordretabel, for vi har med services at gøre, så vi laver en fast pris. den kan der ikke fifles med senere. (Så skulle det da være med timeløn osv. men det opererer kdbén ikke med)
Jeg takker for dit råd Mugs.
Jeg læser det sådan, at jeg laver en ny primær-nøgle i Firma-tabellen som kundenr. Samtidig laver jeg en CVR-kolonne som ikke er unik.

Laver en afdelings-tabel, med en CVR-kolonne som jeg relaterer til firma.cvr

Nu skal jeg så have det sådan at jeg kan se alle afdelinger tilhørende en kommune, både betalingsenheder og rene underafdelilnger.

I hvilken tabel skal jeg indtaste de betalende underafdelinger?

Hvis:
du siger A. (I Firma-tabellen med eget kundenr)
OK Men hvordan kan jeg så i en forespørgsel se, at det er en underafdeling til en anden kunde (nemlig kommunen?), sammen med alle de andre underafdelinger fra afdelingstabellen?

du siger B. (I Afdelings-tabellen)
OK. I afdelingstabellen kan jeg lave en Ja/nej kolonne til "Betalingsenhed?". Men så får de jo ikke noget kundenr?

Hmm noget har jeg måske alligevel allerede fundet ud af. For nu har jeg presset dem lidt i regnskabsafdelingen, og spurgt dem om det VIRKELIG er vigtigt at man kan se en selvejende skole (som er en betalingsenhed) som en underafdeling til kommunen.
Hårdt presset indrømmede de, at det vist ikke er vigtigt.. :_)

Nåmen, hvis du smider et svar Mugs, så får du points.

VH
Tore

.