10. september 2003 - 17:01Der er
19 kommentarer og 1 løsning
Kundedatabase - flere records med samme kundeId
Jeg går med nogle planer om at designe en form for kundedatabase, der skal indeholde normale stamoplysninger over kunderne. Endvidere er det så planen, at denne kundetabel skal relateres til en ordretabel - altså noger i retning af kundeId til ordreId.
Dette er umiddelbart ikke noget problem hvis der kun bestilles én ting til hver ordre, men i tilfælde af, at en kunde har flere varer på én ordre og disse skal udskrives på en faktura med fek,s. antal varer i en given kategori via en løkke - bliver man vel nødt til at gøre noget i retning af:
Udskriv alle records, der har ordreId=OrdreId hvor kunde=KundeId bliver man umiddelbart nødt til at have flere records med samme ordreId?
Er der en nemmere/bedre måde at gøre dette på, da det måske vil blive meget uoverskueligt?
I tilfælde af at én af varerne i ordren er en mere permanent service, der skal faktureres igen efter en given periode vil det også blive svært at adskille dette på den givne ordre.
Ved ikke om jeg har formuleret dette godt nok, men håber på at nogen kan komme med et par gode råd til opbygning af en sådan database - måske så man kommer omkring dette dilemma.
I dette særtema ser vi på, hvordan cloud og AI bliver fundamentet for virksomhedernes digitale forretning, og hvordan de nye muligheder for automatisering og forretningsværdi kan udnyttes uden at miste overblik, sikkerhed og menneskelig kontrol.
Hvis du har denne lags permanente ordrer brude du maaske ogsaa inkludere et felt til ordre-type. Der kan du saa enten lave det som en drop down/look-up funktion hvis du har mere en "normal" og "permanent" eller hvis der kun er de to kan du saette det som et ja/nej felt. Paa den maade kan du udelukke de permanente orderer fra andre faktura.
Lav en tabel med kunde id. Lav en tabel med Fakture id. Det giver svarret, har sådan en testdb, og kan sende den.
Synes godt om
Slettet bruger
10. september 2003 - 17:12#4
Hej Henrik. Det var også min plan at lave flere tabeller. Altså en kundetabel med et Id-felt og en ordretabel med et ordreId-felt. Når man registrer en ordre til en given kunde kan det jo være at denne kunde har bestilt flere varer/services. Hvis man går ud fra at man vælger hvilke varer kunden har valgt og disse varer skal skrives seperat på fakturaen - ligeså meget så systemet ved om det er en vare, der skal registreres som en service, der skal køre løbende og genfaktureres, ja så er man vel nødt til at opdale de forskellige varer der er bestilt. Systemet kan jo ikke ud fra en længere smøre i et notatfelt afgøre hvilke varer der er bestilt???
På denne måde vil der vel unægteligt være behov for at systemet kan oprette seperate records til hver enkelt vare på bestillingen, eller hvad?
Synes godt om
Slettet bruger
10. september 2003 - 17:17#5
Udgangspunktet er forresten, at der på fakturaen skal kunne skrives:
antal 1 vare 1 2 vare2 1 vare 3
Osv. Altså ved hjælp af en løkke når man genererer fakturaen...
1. er et kundekartotek. Hvor du så via sql finder alle kundens bestillinger. 2. er til nye ordre. Er det service du kører med, er det jo rart, at du kan afslutte ordren, (for regnings skuld, og evt. klager).
Normalt vil du skulle have fire tabeller: 1. En kundetabel med al kundeinfo, 2: En varetabel med al vareinfo. 3: En ordretabel ed infor om ordredata, leveringsdato, leveringssted osv og 4: En ordredetaljetabel med info on antal og pris mm for hver vare, der findes på en given ordre.
Mellem Kunde og Ordre har du en 1:N relation. Mellem ordre og ordrelinje ligeledes en 1:N relaton og mellem Vare og Ordrelinje en 1:N relation. Tabellen, der er nævt først er i hvert tilfælde 1-side i relationerne
med en 1:N relation mellem kunde og ordre udelukker du muligheden for at slette kunder senere og dermed vedligeholde din database, så den ikke bliver overfyldt. Det samme med varer etc.
thomaso -> Hvis din db skal indeholde historik (og det skal den vel, da du omtaler services der løbende skal genfakturerer), skal du tænke på prisstigninger. Det er derfor nødvendigt, at allerede faktuerede ordrer (services) gemmes i en separat tabel med de priser, der var gældende på bestillingstidspunktet.
I modsat fald vil allerede fakturerede ordrer blive berørt af prisstigninger.
Synes godt om
Slettet bruger
11. september 2003 - 16:19#11
Mange tak for input til jer alle sammen. I har været til stor hjælp for det videre arbejde og skal have mange tak!
Det er sgu for fedt at man kan få hjælp sådanne steder som her på eksperten.dk!
jkrons: der kommer en ordre fra kunde1. Ordretabellen vil så indeholde kundenr1 og ordrenr1...hvis så du sletter kunde1, peger kundenr1 i ordrenr1 ikke på en eksisterende kunde
riversen-> Enig - men hvis du definerer referentiel integritet kan du løse problem af den vej. Dog mener jeg at en bedre løsning er at "flytte" tidligere kunder til en historiktabel, så referencen stadig kan bevares.
Hvis ordrerne er færdigekspederet og uinteressante kan man slette dem først, óg så slette kunden senere.
Referentiel integritet mellem de to tabeller vil sikre at du ikke kan slette en kunde, der har ordrer - at du altså må slette ordrerne først. Hvis du definerer kaskadevis sletning slettes ordrer automatis
Uanset hvordan du gør det, vil der altid være en 1:N relation mellem Kunde og Order, da en kunde kan have mange ordrer, men en ordre kun kan tilhøre en kunde.
ja, men jeg skrev jo også, hvis man vil slette en kunde. At forhindre sletning er jo ikke nødvendigvis en god ting, da det forhindrer vedligeholdelse af data på længere sigt.
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.
