---

Hejsa!!!

Jeg har lavet en tabel i mysql hvor man via en form på min side skal
indtaste sit postnummer..

Min kode:
<tr><th valign="top" align="left">Postnummer:</th><td><input type="text"
name="postnummer" value="<?=$user[postnummer];?>"></td></tr>

i mysql har jeg sat oplysningerne til at være:
postnummer, tinyint(4), not null

Mit problem.. når jeg prøver at skrive 9300 i min form.. og kigger i mysql
så viser den 127.... Hvorfor tilker den 9300 som 127 og hvordan får jeg den
til at gemme det rigtige tal?

1000 tak
Mette

--
--
Er du klar over at det nu koster 20 øre at sende en sms fra internettet????
Send din klage:
http://nustopperde.zapto.org/

---

"Mette Frederiksen" <rollike@frederiksen.mail.dk> writes:

> i mysql har jeg sat oplysningerne til at være:
> postnummer, tinyint(4), not null

Skidt valg. Snup et kig på
<http://www.mysql.com/doc/C/o/Column_types.html>, og se at Tinyint kan
bruges til at indeholde værdier mellem -128 og 127.

Smallint skulle kunne gøre tricket for dig, så længe vi kun snakker om
danske postnumre.

--
Jacob - www.bunk.cc
Needs are a function of what other people have.

---

>
> Skidt valg. Snup et kig på
> <http://www.mysql.com/doc/C/o/Column_types.html>, og se at Tinyint kan
> bruges til at indeholde værdier mellem -128 og 127.

*G* ahhh den kan ikke tælle længere end til 127! *S*
>
> Smallint skulle kunne gøre tricket for dig, så længe vi kun snakker om
> danske postnumre.

Jamen det er jo det jeg skal bruge så! *S*

mvh Mette.

---

"Mette Frederiksen" <rollike@frederiksen.mail.dk> skrev i en meddelelse
news:ad75in$jgm$1@sunsite.dk...
>
> >
> > Skidt valg. Snup et kig på
> > <http://www.mysql.com/doc/C/o/Column_types.html>, og se at Tinyint kan
> > bruges til at indeholde værdier mellem -128 og 127.
>
> *G* ahhh den kan ikke tælle længere end til 127! *S*
> >
> > Smallint skulle kunne gøre tricket for dig, så længe vi kun snakker om
> > danske postnumre.
>
> Jamen det er jo det jeg skal bruge så! *S*

Hej Mette

Jeg ville med (danske) postnumre vælge CHAR(4), da du alligevel ikke skal
bruge nummeret til at udfører matematiske beregninger

John

---

"John Larsen" <jola_at_get2net_dot_dk> skrev:
>
> Jeg ville med (danske) postnumre vælge CHAR(4), da du alligevel ikke
> skal bruge nummeret til at udfører matematiske beregninger

Sikker? Man kunne sagtens forestille sig, at man f.eks. i en e-butik
skulle forhøje fragtprisen på baggrund af, hvilket postnummerområde et
bestemt postnummer befinder sig i.

--
Jonas Koch Bentzen

---

"Jonas Koch Bentzen" <ingen.email@eksempel.dk> skrev i en meddelelse
news:ad7h0k$lqo$1@sunsite.dk...
> "John Larsen" <jola_at_get2net_dot_dk> skrev:
> >
> > Jeg ville med (danske) postnumre vælge CHAR(4), da du alligevel ikke
> > skal bruge nummeret til at udfører matematiske beregninger
>
> Sikker? Man kunne sagtens forestille sig, at man f.eks. i en e-butik
> skulle forhøje fragtprisen på baggrund af, hvilket postnummerområde et
> bestemt postnummer befinder sig i.

Og det kunne man da sagtens sorterer i en streng - eller hvad ?

I mit liv har jeg ALDRIG brugt andet end stringfields til postnumre, og JO
jeg benytter meget range, for nu at checke på sjælland (bornholm), fyn og
jylland


John

---

> Og det kunne man da sagtens sorterer i en streng - eller hvad ?
>
> I mit liv har jeg ALDRIG brugt andet end stringfields til postnumre, og JO
> jeg benytter meget range, for nu at checke på sjælland (bornholm), fyn og
> jylland

Ja, men teoretisk kan du ikke sige at hvis en streng er større end 5000 så
skal den forhøje fragtprisen. PHP har dog den feature at den automatisk så
finder ud af at konvertere det til en integer! Men men men... rent programmelt
er det ikke pænt...

mvh
Johan

---

"John Larsen" <jola_at_get2net_dot_dk> skrev:

>
> "Jonas Koch Bentzen" <ingen.email@eksempel.dk> skrev i en meddelelse
> news:ad7h0k$lqo$1@sunsite.dk...
>> "John Larsen" <jola_at_get2net_dot_dk> skrev:
>> >
>> > Jeg ville med (danske) postnumre vælge CHAR(4), da du alligevel
>> > ikke skal bruge nummeret til at udfører matematiske beregninger
>>
>> Sikker? Man kunne sagtens forestille sig, at man f.eks. i en e-butik
>> skulle forhøje fragtprisen på baggrund af, hvilket postnummerområde
>> et bestemt postnummer befinder sig i.
>
> Og det kunne man da sagtens sorterer i en streng - eller hvad ?

I PHP, ja - men hvorfor ikke holde udregningen nede i databasen?

> I mit liv har jeg ALDRIG brugt andet end stringfields til postnumre

Så var det da på tide, at du gør det nu : )

--
Jonas Koch Bentzen

---

> > I mit liv har jeg ALDRIG brugt andet end stringfields til postnumre
>
> Så var det da på tide, at du gør det nu : )

Helt enig...
At smide den i en string felt er blot at begrænse sig alt for meget... :) Og
hvorfor dog gøre det :)

mvh
Johan

---

After drinking 3 Pan Galactic Gargle Blasters, "John Larsen"
<jola_at_get2net_dot_dk> mumbled in news:3cf7393c$0$18629
$edfadb0f@dspool01.news.tele.dk:
> "Mette Frederiksen" <rollike@frederiksen.mail.dk> skrev i en
> meddelelse news:ad75in$jgm$1@sunsite.dk...
>>> Smallint skulle kunne gøre tricket for dig, så længe vi kun
>>> snakker om danske postnumre.
>> Jamen det er jo det jeg skal bruge så! *S*
> Jeg ville med (danske) postnumre vælge CHAR(4), da du alligevel
> ikke skal bruge nummeret til at udfører matematiske beregninger
>

Undskyld, men danske postnumre er et tal! Hvorfor lave det til
tegn, med risiko for at man laver en fejl en dag og kommer til
at skrive alt muligt i basen? Det er da bedre at forhindre det
ved at lade typen afspejle indholdet. Desuden kunne det jo være
at man ville lave en sammenligning a la postnr < 1000, osv.

Andrew
--
*** The opinions expressed are not necessarily those of my employer. ***
* Software Engineer Andrew Engels Rump * BLIK og ROERarbejderforbundet *
* Immerkaer 42, 2650 Hvidovre * Tlf: +45 3638 3638, Fax: +45 3638 3639 *
Home: N55°41'38.9" E12°29'08.6" (WGS 84) Work: N55°39'50.9" E12°27'47.4"
E-mail: mailto:newandrew@rump.dk WWW http://www.rump.dk/homepage/andrew/

---

"Andrew Engels Rump (formerly Leif Andrew Rump)" <newandrew@rump.dk> skrev i
en meddelelse news:Xns921F93CC5600Enewandrewrumpdk@212.242.40.196...
> After drinking 3 Pan Galactic Gargle Blasters, "John Larsen"
> <jola_at_get2net_dot_dk> mumbled in news:3cf7393c$0$18629
> $edfadb0f@dspool01.news.tele.dk:
> > "Mette Frederiksen" <rollike@frederiksen.mail.dk> skrev i en
> > meddelelse news:ad75in$jgm$1@sunsite.dk...
> >>> Smallint skulle kunne gøre tricket for dig, så længe vi kun
> >>> snakker om danske postnumre.
> >> Jamen det er jo det jeg skal bruge så! *S*
> > Jeg ville med (danske) postnumre vælge CHAR(4), da du alligevel
> > ikke skal bruge nummeret til at udfører matematiske beregninger
> >
>
> Undskyld, men danske postnumre er et tal! Hvorfor lave det til
> tegn, med risiko for at man laver en fejl en dag og kommer til
> at skrive alt muligt i basen? Det er da bedre at forhindre det
> ved at lade typen afspejle indholdet. Desuden kunne det jo være
> at man ville lave en sammenligning a la postnr < 1000, osv.

Foranlediget af alt påstyret har jeg skyndt mig lidt at grave i mine kilder
...... - og :

SELECT DISTINCT PostNr
FROM Zip
WHERE
(PostNr > '1000')
ORDER BY PostNr

Giver et fuldgyldigt resultat, så undskyld mange gange hvad er der galt med
at sammenligne strenge ?
For at komme tilbage til normalisering af databaser, så er en af
diciplinerne at finde ud af HVAD man skal bruge felter til og man tager ikke
Tårnby og lægger Viby til trækker Slagelse fra og dividerer med Århus C for
at finde ud af at der skal forhøjelse af taksterne til Kastrup vel ? Jeres
metode med at stoppe postnumrene i smallintfelter giver OGSÅ en
fejlmulighed, hvad hvis jeg er lidt hurtig og taster 27770 ? det er IKKE et
gyldigt dansk postnummer, men det ER en gyldig smallint, det er derimod IKKE
en gyldig CHAR(4).

John

---

"John Larsen" <jola_at_get2net_dot_dk> writes:

> SELECT DISTINCT PostNr
> FROM Zip
> WHERE
> (PostNr > '1000')
> ORDER BY PostNr
>
> Giver et fuldgyldigt resultat, så undskyld mange gange hvad er der galt med
> at sammenligne strenge ?

Lige indtil en eller anden finder på at bruge et tegnsæt, hvor tegnene
står i omvendt rækkefølge af hvad du er vant til, eller noget andet
fjollet.

> For at komme tilbage til normalisering af databaser, så er en af
> diciplinerne at finde ud af HVAD man skal bruge felter til og man tager ikke
> Tårnby og lægger Viby til trækker Slagelse fra og dividerer med Århus C for
> at finde ud af at der skal forhøjelse af taksterne til Kastrup vel ?

Hvad har det med normalisering at gøre?

Vi er enige om at det har at gøre med at finde den rette datatype og
aritmetik, men jeg kan altså ikke hvad det har med normalisering at
gøre.

> Jeres metode med at stoppe postnumrene i smallintfelter giver OGSÅ
> en fejlmulighed, hvad hvis jeg er lidt hurtig og taster 27770 ? det
> er IKKE et gyldigt dansk postnummer, men det ER en gyldig smallint,
> det er derimod IKKE en gyldig CHAR(4).

Hvis man vil være sikker på ikke at få forkerte ting i sin database,
og man i øvrigt normaliserer den, så vil man fx ofte have en tabel med
postnummer og by (den kan vist findes på Post Danmarks hjemmeside et
sted), og så vil man jo validere om postnummeret overhovedet er
gyldigt før man sætter det ind. Det er fx ikke alle numre der er
gyldige bare fordi de er mellem 1000 og 9999.

Endvidere er det da tåbeligt at bruge 4 bytes pr. kolonne (CHAR(4))
når man kan nøjes med 2 (SMALLINT).

--
Jacob - www.bunk.cc
Never forget what a man says to you when he is angry.