---

Hejsa,

jeg har været lidt i tvivl om man måtte bruge cpr og cvr nr
som kundenr, men har fundet frem til at ingen af dem er
hensigtsmæssige.
Det sidste bud er et autogenererende kundenr, kædet
sammen med kundens adresse, tlfnr, email osv.
Dette gør man nemt kan ændre alle informationer, da
relationerne knyttes til kundenummeret.

Helt konkret, er vi ved at lave et eksamensprojekt,
hvor vi skal udvikle et EDB-system til administrering
af værelsesudlejning på et hotel.
Vi ville så bruge cpr nr, som kundenr til private og SE nr,
som kundenr til erhverv, men disse er nu forkastet til
fordel for føromnævnte.

Har I bedre idéer?

Mvh.
Mikael

---

On Fri, 24 May 2002 07:38:34 +0200, Mikael Nørrelund Andersen
<noerrelund@pc.dk> wrote:

>Hejsa,
>
>jeg har været lidt i tvivl om man måtte bruge cpr og cvr nr
>som kundenr, men har fundet frem til at ingen af dem er
>hensigtsmæssige.
>Det sidste bud er et autogenererende kundenr, kædet
>sammen med kundens adresse, tlfnr, email osv.
>Dette gør man nemt kan ændre alle informationer, da
>relationerne knyttes til kundenummeret.
>
>Helt konkret, er vi ved at lave et eksamensprojekt,
>hvor vi skal udvikle et EDB-system til administrering
>af værelsesudlejning på et hotel.
>Vi ville så bruge cpr nr, som kundenr til private og SE nr,
>som kundenr til erhverv, men disse er nu forkastet til
>fordel for føromnævnte.
>
>Har I bedre idéer?

mange bruger tlf.nummer

--
vh
Thomas Jensen, pil.dk
Bliv partner: http://pil.dk/partner/

---

"Thomas Jensen - pil.dk" <tj@dev.null> wrote in message
news:96oreu4foj5h9281jfalaf68jdjvni9gd8@4ax.com...
> On Fri, 24 May 2002 07:38:34 +0200, Mikael Nørrelund Andersen
> <noerrelund@pc.dk> wrote:
>
> >Vi ville så bruge cpr nr, som kundenr til private og SE nr,
> >som kundenr til erhverv, men disse er nu forkastet til
> >fordel for føromnævnte.
> >
> >Har I bedre idéer?
>
> mange bruger tlf.nummer
>
Historien har vist er det kan være en lidt skidt idé - hvis man bruger tlfnr
som primary key

Fx i Københavns området har det givet en del konsulenter ekstra penge i
kassen ved datakonverteringer pga ændring af telefonnummer (dikteret af
ktas/teledanmark)

mvh/Peter Lykkegaard

---

On Fri, 24 May 2002 10:36:15 +0200, "Peter Lykkegaard"
<polonline@hotmail.com> wrote:

>
>"Thomas Jensen - pil.dk" <tj@dev.null> wrote in message
>news:96oreu4foj5h9281jfalaf68jdjvni9gd8@4ax.com...
>> On Fri, 24 May 2002 07:38:34 +0200, Mikael Nørrelund Andersen
>> <noerrelund@pc.dk> wrote:
>>
>> >Vi ville så bruge cpr nr, som kundenr til private og SE nr,
>> >som kundenr til erhverv, men disse er nu forkastet til
>> >fordel for føromnævnte.
>> >
>> >Har I bedre idéer?
>>
>> mange bruger tlf.nummer
>>
>Historien har vist er det kan være en lidt skidt idé - hvis man bruger tlfnr
>som primary key

jeg skulle nok ikke være nøjes m. en oneliner

nøglen overfor kunderne kan være tlf.
internt i databasesammenhæng finder på man et unikt fortløbende
kunde_id

--
vh
Thomas Jensen, pil.dk
Bliv partner: http://pil.dk/partner/

---

"Thomas Jensen - pil.dk" wrote:
>
> On Fri, 24 May 2002 07:38:34 +0200, Mikael Nørrelund Andersen
> <noerrelund@pc.dk> wrote:
>
> >Hejsa,
> >
> >jeg har været lidt i tvivl om man måtte bruge cpr og cvr nr
> >som kundenr, men har fundet frem til at ingen af dem er
> >hensigtsmæssige.
> >Det sidste bud er et autogenererende kundenr, kædet
> >sammen med kundens adresse, tlfnr, email osv.
> >Dette gør man nemt kan ændre alle informationer, da
> >relationerne knyttes til kundenummeret.
> >
> >Helt konkret, er vi ved at lave et eksamensprojekt,
> >hvor vi skal udvikle et EDB-system til administrering
> >af værelsesudlejning på et hotel.
> >Vi ville så bruge cpr nr, som kundenr til private og SE nr,
> >som kundenr til erhverv, men disse er nu forkastet til
> >fordel for føromnævnte.
> >
> >Har I bedre idéer?
>
> mange bruger tlf.nummer

Gys.

Hvad gør de så, hvis folk flytter?

Man bliver så nødt til at have både kundenr og tlfnr.

Og endnu værre, når det gamle tlf.nr bliver udleveret til en til
TDC-bruger og vedkommende ringer til det samme firma.

Jeg kender ikke noget officielt, eviggyldigt og uforanderligt nummer,
der kan bruges til nøgle. Autogenererede nøgler har mange fordele, men
at du selv har fuld kontrol over dem er nu den største.

--
Kristian Damm Jensen | Feed the hungry at www.thehungersite.com
kristian-damm.jensen@cgey.com | Two wrongs doesn't make a right,
ICQ# 146728724 | but three lefts do.

---

On Fri, 24 May 2002 11:33:30 +0200, Kristian Damm Jensen
<kristian-damm.jensenRE@MOVEcgey.com> wrote:

>
>Hvad gør de så, hvis folk flytter?
>
>Man bliver så nødt til at have både kundenr og tlfnr.
>
>Og endnu værre, når det gamle tlf.nr bliver udleveret til en til
>TDC-bruger og vedkommende ringer til det samme firma.

Eller når 500 mennesker på det samme kollegium har samme telefonnummer
....
--
Nis Jorgensen
Amsterdam

Please include only relevant quotes, and reply below the quoted text. Thanks

---

---

"Jan Eliasen" <jan@eliasen.dk> skrev:
> At begynde at kræve at lejere på et hotel oplyser cpr-nummer,
> det er i hvert fald helt hen i vejret (citat: Sebstian

Det er vi også kommet frem til, jeg havde jo bare skrevet
vores diskussion ned.

> Som en anden nævnte, så kan telefonnummer bruges, men telefonnumre kan jo
> ændres (når man flytter osv.). Så jeg ville nok bruge en maskingenereret
> nøgle som kundenummer, men ikke gøre nogen kunder opmærksom på at I har et
> sådant internt kundenummer - bare have nok oplysninger i databasen til at
> I kan finde en kundes kundenummer ud fra f.eks. hans telefonnummer eller
> lignende.

Ok, det vil vi nævne i vores rapport.

Mange tak for hjælpen.

Mvh.
Mikael


--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

---

Jan Eliasen <jan@eliasen.dk> skrev:

> Som en anden nævnte, så kan telefonnummer bruges, men
> telefonnumre kan jo ændres (når man flytter osv.).

En mulighed er at benytte telefonnummeret som kundenummer - men
samtidig registrere nummeret i et egentlig telefon-felt. Hvis
kunden så skifter nummer, ændres primærnøglen ikke, alene
telefonfeltet opdateres. På den måde vil man hurtigt kunne finde
mange kunder - uden at få problemer med skiftende nøgleværdier.

--
Jens Gyldenkærne Clausen
MF (medlem af FIDUSO - www.fiduso.dk)

---

"Jens Gyldenkærne Clausen" wrote:
>
> Jan Eliasen <jan@eliasen.dk> skrev:
>
> > Som en anden nævnte, så kan telefonnummer bruges, men
> > telefonnumre kan jo ændres (når man flytter osv.).
>
> En mulighed er at benytte telefonnummeret som kundenummer - men
> samtidig registrere nummeret i et egentlig telefon-felt. Hvis
> kunden så skifter nummer, ændres primærnøglen ikke, alene
> telefonfeltet opdateres. På den måde vil man hurtigt kunne finde
> mange kunder - uden at få problemer med skiftende nøgleværdier.

Og så bede til at det samme telefonnummer ikke kommer igen - med en
kunde.


--
Kristian Damm Jensen | Feed the hungry at www.thehungersite.com
kristian-damm.jensen@cgey.com | Two wrongs doesn't make a right,
ICQ# 146728724 | but three lefts do.

---

Kristian Damm Jensen <kristian-damm.jensenRE@MOVEcgey.com>
skrev:

> Og så bede til at det samme telefonnummer ikke kommer igen -
> med en kunde.

Så opretter man bare kunden med en anden nøgle. Metoden anvendes i
praksis i et bookingsystem jeg arbejder med (men ikke har
udviklet). Det gør en del indtastninger lettere at man i 95 % af
tilfældene eller mere kan gætte sig til primærnøglen.

--
Jens Gyldenkærne Clausen
MF (medlem af FIDUSO - www.fiduso.dk)

---

"Jens Gyldenkærne Clausen" <jc@dmf.dk> wrote in message
news:Xns92187A63896C3jcdmfdk@130.225.247.90...
> Kristian Damm Jensen <kristian-damm.jensenRE@MOVEcgey.com>
> skrev:
>
> > Og så bede til at det samme telefonnummer ikke kommer igen -
> > med en kunde.
>
> Så opretter man bare kunden med en anden nøgle. Metoden anvendes i
> praksis i et bookingsystem jeg arbejder med (men ikke har
> udviklet). Det gør en del indtastninger lettere at man i 95 % af
> tilfældene eller mere kan gætte sig til primærnøglen.
>
Jeg går nu stadig ind for at generisk primary key der ikke kan
ses/bruges/søges på af brugerne men bruges udelukkende af systemet som
reference (foreign key)

mvh/Peter Lykkegaard

---

Jeg er meget enige med Peter Lykkegaard...

man har intet at bruge den primary key til ... den bruges kun som object
identifier ... og reference imellem tabellerne ... derfor har dens værdi
ikke den store betydning. Lad for gud's skyld være med at vælge en primary
key der knytter sig til "virksomheden". den kan altid ændres ... det kan en
"opfunden" ikke .. den har man selv kontrol over ...

Tonni Schmücker

"Peter Lykkegaard" <polonline@hotmail.com> skrev i en meddelelse
news:3cee103d$0$70414$edfadb0f@dspool01.news.tele.dk...
>
> "Jens Gyldenkærne Clausen" <jc@dmf.dk> wrote in message
> news:Xns92187A63896C3jcdmfdk@130.225.247.90...
> > Kristian Damm Jensen <kristian-damm.jensenRE@MOVEcgey.com>
> > skrev:
> >
> > > Og så bede til at det samme telefonnummer ikke kommer igen -
> > > med en kunde.
> >
> > Så opretter man bare kunden med en anden nøgle. Metoden anvendes i
> > praksis i et bookingsystem jeg arbejder med (men ikke har
> > udviklet). Det gør en del indtastninger lettere at man i 95 % af
> > tilfældene eller mere kan gætte sig til primærnøglen.
> >
> Jeg går nu stadig ind for at generisk primary key der ikke kan
> ses/bruges/søges på af brugerne men bruges udelukkende af systemet som
> reference (foreign key)
>
> mvh/Peter Lykkegaard
>
>
>
>

---

---

Jan Eliasen <jan@eliasen.dk> skrev:

> Er det ikke stort set det samme som en genereret primærnøgle,
> der bare for det meste er den samme som telefonummeret?

Ikke i min terminologi. En genereret primærnøgle frembringes
"uberørt af menneskehånd" - altså uden nogen som helst indtastning.

--
Jens Gyldenkærne Clausen
MF (medlem af FIDUSO - www.fiduso.dk)

---

Det er et evigt problem.
Det er meget afhængigt af branche og kundetyper.
Hvis I valgte cprnr på private på et hotel, kan du ikke have internationale kunder.
Skal kunderne afvises når deres Cprnr ikke godkendes af jeres validering?
Cprnr er godt, når det skal være kendt ifølge lovgivning.
Er der mange stamkunder, der skal kunne huske sit kundenr så er tlfnr godt, men det
har som andre har skrevet også bagdele.
SE/CVR er godt for virksomheder, når bare ikke de skal registreres med forskellige
filialer/afdelinger med samme SE/CVR nr.
En autogenereret nøgle kender kunden ikke, og hvis I skriver det på fakturaer, skal
de først slå det op.
Løsningen afhænger af situationen.

Man kan også have unikke nøgler, der ikke er primærnøglen, og det er tit løsningen
sammen med en autogenereret primærnøgle.

Gennemtænkt nøje alle situationer i jeres case, for nem indtastning, eventuel
ændring, om kunden skal kunne huske det osv.

venlig hilsen

Arne Markland
PowerBase ApS

Fri, 24 May 2002 07:38:34 +0200, Mikael Nørrelund Andersen <noerrelund@pc.dk> skrev:
> Hejsa,
>
> jeg har været lidt i tvivl om man måtte bruge cpr og cvr nr
> som kundenr, men har fundet frem til at ingen af dem er
> hensigtsmæssige.
> Det sidste bud er et autogenererende kundenr, kædet
> sammen med kundens adresse, tlfnr, email osv.
> Dette gør man nemt kan ændre alle informationer, da
> relationerne knyttes til kundenummeret.
>
> Helt konkret, er vi ved at lave et eksamensprojekt,
> hvor vi skal udvikle et EDB-system til administrering
> af værelsesudlejning på et hotel.
> Vi ville så bruge cpr nr, som kundenr til private og SE nr,
> som kundenr til erhverv, men disse er nu forkastet til
> fordel for føromnævnte.
>
> Har I bedre idéer?
>
> Mvh.
> Mikael
>

---

"Arne Markland" <am@powerbase.dk> skrev:
> Det er meget afhængigt af branche og kundetyper.

Ja, det er klart.

> Hvis I valgte cprnr på private på et hotel, kan du ikke have internationale kunder.

Det er også en af de ting vi er kommet frem til og derfor har kasseret
denne idé.
Vi tænkte måske også for langt, fordi i tilfælde af brand, ved hotellet
præcis hvem der bor på hotellet!

> Skal kunderne afvises når deres Cprnr ikke godkendes af jeres validering?

Endnu en af grundene til at vælge noget andet.

> Cprnr er godt, når det skal være kendt ifølge lovgivning.

Ja, fx bibliotek og læge mv.

> Er der mange stamkunder, der skal kunne huske sit kundenr så er tlfnr godt, men det
> har som andre har skrevet også bagdele.

Ja, hvis de fx. skifter telefonnr. Derfor kigger vi lidt på en
autogenereret nøgle, som ikke bliver offentlig. Offentligt er tlfnr
kundenr.

> SE/CVR er godt for virksomheder, når bare ikke de skal registreres med forskellige
> filialer/afdelinger med samme SE/CVR nr.

Her er førnævnte mulighed igen at foretrække.

> En autogenereret nøgle kender kunden ikke, og hvis I skriver det på fakturaer,
> skal de først slå det op.

Ikke hvis det er kundens tlfnr der står som kundenr.

> Løsningen afhænger af situationen.

Nemlig, men i vores tilfælde med et hotel, bør min sidste løsning så
ikke række?

> Man kan også have unikke nøgler, der ikke er primærnøglen,
> og det er tit løsningen sammen med en autogenereret primærnøgle.

Det må være den løsning jeg har beskrevet.

> Gennemtænkt nøje alle situationer i jeres case, for nem indtastning, eventuel
> ændring, om kunden skal kunne huske det osv.

Igen mener jeg den sidste løsning dækker det hele, kunden kan endda
findes vha. email adresse eller navn også vha. en søgefunktion!

Nu tænker jeg på udenlandske kunder, så er en validering af tlfnr
måske ikke så smart, det er svjv ikke alle lander der har 8 cifre i
tlfnr, vel?

Venligst
Mikael


--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

---

On Sat, 25 May 2002 11:11:42 +0000 (UTC), "Mikael N. Andersen"
<noerrelund@pc.dk> wrote:

>
>> Er der mange stamkunder, der skal kunne huske sit kundenr så er tlfnr godt, men det
>> har som andre har skrevet også bagdele.
>
>Ja, hvis de fx. skifter telefonnr. Derfor kigger vi lidt på en
>autogenereret nøgle, som ikke bliver offentlig. Offentligt er tlfnr
>kundenr.

Hvad med kunder der:

1. Ikke har telefon
2. Har samme telefonnummer som andre kunder


>Igen mener jeg den sidste løsning dækker det hele, kunden kan endda
>findes vha. email adresse eller navn også vha. en søgefunktion!
>
>Nu tænker jeg på udenlandske kunder, så er en validering af tlfnr
>måske ikke så smart, det er svjv ikke alle lander der har 8 cifre i
>tlfnr, vel?

Bestemt ikke. Det betyder selvfølgelig ikke at I ikke kan validere
dem.

--
Nis Jorgensen
Amsterdam

Please include only relevant quotes, and reply below the quoted text. Thanks

---

"Nis Jorgensen" <nis@dkik.dk> wrote:
> Hvad med kunder der:
>
> 1. Ikke har telefon
> 2. Har samme telefonnummer som andre kunder

Det bliver intet problem, vi laver en søgefunktion, der kan søge på
andet end tlfnr.
Husk på vores primærnøgle er autogenereret.

> >Igen mener jeg den sidste løsning dækker det hele, kunden kan endda
> >findes vha. email adresse eller navn også vha. en søgefunktion!
> >
> >Nu tænker jeg på udenlandske kunder, så er en validering af tlfnr
> >måske ikke så smart, det er svjv ikke alle lander der har 8 cifre i
> >tlfnr, vel?
>
> Bestemt ikke. Det betyder selvfølgelig ikke at I ikke kan validere
> dem.

Det gør vi heller ikke ;)

Venligst
Mikael


--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

---

On Tue, 28 May 2002 07:46:31 +0000 (UTC), "Mikael N. Andersen"
<noerrelund@pc.dk> wrote:

>"Nis Jorgensen" <nis@dkik.dk> wrote:
>> Hvad med kunder der:
>>
>> 1. Ikke har telefon
>> 2. Har samme telefonnummer som andre kunder
>
>Det bliver intet problem, vi laver en søgefunktion, der kan søge på
>andet end tlfnr.
>Husk på vores primærnøgle er autogenereret.

I har noget som i kalder "kundenummer". Dette er ikke unikt. Dette
mener jeg er et problem.

>> >Nu tænker jeg på udenlandske kunder, så er en validering af tlfnr
>> >måske ikke så smart, det er svjv ikke alle lander der har 8 cifre i
>> >tlfnr, vel?
>>
>> Bestemt ikke. Det betyder selvfølgelig ikke at I ikke kan validere
>> dem.
>
>Det gør vi heller ikke ;)

Jeg tror du er løbet sur i negationerne, enten i min sætning eller i
dit svar. Jeg skriver at I godt kan validere internationale numre. Du
skriver at det gør I heller ikke.

--
Nis Jorgensen
Amsterdam

Please include only relevant quotes, and reply below the quoted text. Thanks

---

"Nis Jorgensen" <nis@dkik.dk> skrev:
> I har noget som i kalder "kundenummer". Dette er ikke
> unikt. Dette mener jeg er et problem.

Kundenr er måske et stærkt ord, det hedder bare tlfnr i
systemet!
Kundenummeret er ikke offentligt, vi finder bare kunderne
vha. søgninger på fx. tlfnr eller email.

> > > >Nu tænker jeg på udenlandske kunder, så er en
> > > > validering af tlfnr måske ikke så smart, det er svjv
> > > > ikke alle lander der har 8 cifre i tlfnr, vel?
> >>
> >> Bestemt ikke. Det betyder selvfølgelig ikke at I ikke
> > > kan validere dem.
> >
> >Det gør vi heller ikke ;)
>
> Jeg tror du er løbet sur i negationerne, enten i min
> sætning eller i dit svar. Jeg skriver at I godt kan validere
> internationale numre. Du skriver at det gør I heller ikke.

Som jeg (stadig) læser dit svar, skriver du at vi ikke kan
validere tlfnr, da udenlandske numre fx. er på mere end
8 cifre.
Og så skriver jeg, at det gør vi heller ikke!
Hvor er problemet?
- Anyway, vi mener at have løst vores problem på en god
måde og det er vel det!

Venligst
Mikael

---

Mikael Nørrelund Andersen <noerrelund@pc.dk> skrev:

>> >> Bestemt ikke. Det betyder selvfølgelig ikke at I ikke
>> >> kan validere dem.

>> Jeg tror du er løbet sur i negationerne

> Som jeg (stadig) læser dit svar, skriver du at vi ikke kan
> validere tlfnr, da udenlandske numre fx. er på mere end
> 8 cifre.

Nej - det er ikke hvad han skrev. Fjern 2 x "ikke", så står der:

>> >> Det betyder selvfølgelig at I kan validere dem.

Det er ikke helt den samme betydning som med de 2 "ikke'r", men det
er egentlig kun pga. ordet "selvfølgelig".


> Og så skriver jeg, at det gør vi heller ikke!
> Hvor er problemet?

Nis skriver: I kan godt validere udenlandske telefonnumre.
Du skriver: Det gør vi heller ikke.

Kan du se det nu?

> - Anyway, vi mener at have løst vores problem på en god
> måde og det er vel det!

Bestemt - tillykke med det.

--
Jens Gyldenkærne Clausen
MF (Medlem af Fiduso - www.fiduso.dk)