"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