---

Hej

Jeg er ved at opbygge en mySQL-database til brug til en php-side, jeg er ved
at lave. Databasen skal blandt andet kunne indeholde oplysninger om
registrerede brugere (dvs. bl.a. navn, adresse, email, icq osv). Det er dog
ikke sikkert, at alle f.eks. har et icq-nummer, hvilket leder jeg frem til
spørgsmålet:

Hvad er det bedste, enten benytte null-værdier, bare skrive 0 i feltet eller
splitte min bruger-tabel ud over flere tabeller?

Jeg mener, at forskellige databasebøger, jeg har læst, ikke skriver meget
pænt om null-felter, så dem ville jeg umiddelbart helst undgå. Det med at
splitte tabellen op, så jeg f.eks. har icq-nummer og primærnøglen fra
bruger-tabellen synes jeg er en lidt bøvlet løsning, da der er ret mange
felter, hvor det er valgfrit om man udfylder. Det jeg er kommet frem til, at
nok at jeg bare skriver "0" i felter der er "tomme".

Kommentarer...?

/Jeppe

---

Jeppe Vesterbæk wrote:

> Hvad er det bedste, enten benytte null-værdier, bare skrive 0 i feltet
> eller splitte min bruger-tabel ud over flere tabeller?

Brug null. Og lad i hvert fald være med at splitte din tabel op. Vær i
øvrigt opmærksom på, at null /kan/ (jeg kender ikke mySQL) opføre sig
lidt specielt, når du laver sammenligninger. F.eks er begge flg. udtryk
falske:

3 >= null
3 <= null

Når du tester mod et felt, der kan være null, skal du i stedet bruge
isnull: 'isnull(v) or 3 <= v' eller endnu mere avanceret: '3 <= v (+)'.

-Claus

---

On Sun, 14 Jul 2002 16:04:59 +0200, Claus Rasmussen
<clr@cc-consult.dk> wrote:

>
>Når du tester mod et felt, der kan være null, skal du i stedet bruge
>isnull: 'isnull(v) or 3 <= v' eller endnu mere avanceret: '3 <= v (+)'.

Det sidste er dog ikke standard.

--
Nis Jorgensen
Amsterdam

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

---

Jeppe Vesterbæk wrote in <agrtn5$kft$1@sunsite.dk>:
> (dvs. bl.a. navn, adresse, email, icq osv). Det er
> dog ikke sikkert, at alle f.eks. har et icq-nummer, hvilket leder jeg frem
> til spørgsmålet:
>
> Hvad er det bedste, enten benytte null-værdier, bare skrive 0 i feltet
> eller splitte min bruger-tabel ud over flere tabeller?

I hvert fald ikke splitte det op i flere tabeller. :)

Jeg plejer bare at gemme en tom streng. Det er uhyggeligt simpelt, og jeg
kan ikke lige se hvilke problemer det skulle give.

Der er dog grænser for hvor meget jeg ved om databaser, så det kunne da
egentlig være sjovt nok at høre hvorfor jeg skulle tjekke for tomme
strenge, og lave dem til null, og den anden vej senere hen.

--
Mvh.

Niels Andersen
(la nels. anersyn.)

---

Niels Andersen skrev:
>
> Jeg plejer bare at gemme en tom streng.

Jeppe gemmer et 0, du gemmer en tom streng... Har I aldrig hørt om
"DEFAULT etellerandet" i kolonnedefinitioner? : )

---

Jonas Koch Bentzen wrote in <3D319ACB.2080709@eksempel.dk>:
>> Jeg plejer bare at gemme en tom streng.
> Jeppe gemmer et 0, du gemmer en tom streng... Har I aldrig hørt om
> "DEFAULT etellerandet" i kolonnedefinitioner? : )

Jeg har så default til at være en tom streng. Og hvis folk ikke udfylder et
felt, så får jeg en tom streng. Så synes jeg da det er langt nemmere bare
at indsætte værdien, end at skulle tjekke om den nu lige skulle være tom,
og så ikke indsætte noget. Resultatet bliver jo det samme. Måske en lille
anelse performance-forskel. Men mon ikke det man reder i databasen går tabt
i det, der er foran?

--
Mvh.

Niels Andersen
(la nels. anersyn.)

---

Niels Andersen skrev:
> Jonas Koch Bentzen wrote in <3D319ACB.2080709@eksempel.dk>:
>
>>>Jeg plejer bare at gemme en tom streng.
>>
>>Jeppe gemmer et 0, du gemmer en tom streng... Har I aldrig hørt om
>>"DEFAULT etellerandet" i kolonnedefinitioner? : )
>
>
> Jeg har så default til at være en tom streng. Og hvis folk ikke udfylder et
> felt, så får jeg en tom streng. Så synes jeg da det er langt nemmere bare
> at indsætte værdien, end at skulle tjekke om den nu lige skulle være tom,
> og så ikke indsætte noget.

Du behøver jo ikke at tjekke, om den er tom, og så lade være med at
indsætte noget. Hvorfor skulle du gøre det?

Pointen er, at de gange, hvor du kører en INSERT, men brugeren ikke skal
indtaste alle sine oplysninger den her gang, så er du - hvis du ikke
bruger DEFAULT - tvunget til at indsætte en tom streng, hvis altså dit
script senere får brug for at tjekke værdien af feltet. Et eksempel: Lad
os sige, at vi har en tabel, der ser sådan her ud:

CREATE TABLE brugere (
id SERIAL,
navn CHARACTER VARYING(100),
adresse CHARACTER VARYING(250)
);

På den side, hvor brugeren skal oprette sig, skal han kun indtaste
navnet - adressen kommer senere. Hvis vi nu forestiller os, at dit
script nogle gange efter en SELECT tjekker på, om værdien af adresse er
tom, ja, så bliver du nødt til at indskrive en tom streng i INSERT'en:

INSERT INTO brugere ( navn, adresse ) VALUES ( 'Niels', '' );

Hvis du derimod havde sat DEFAULT '' på adresse, så kunne du have
nøjedes med følgende:

INSERT INTO brugere ( navn ) VALUES ( 'Niels' );

---

Jonas Koch Bentzen wrote in <3D31A0E0.4030703@eksempel.dk>:
> Pointen er, at de gange, hvor du kører en INSERT, men brugeren ikke skal
> indtaste alle sine oplysninger den her gang, så er du - hvis du ikke
> bruger DEFAULT - tvunget til at indsætte en tom streng,

Oh ja, det er da klart nok. :)
Det er netop derfor jeg (næsten) altid har en fornuftig default. :)

Jeg tænkte på situationen, hvor man på en html-side udfylder en masse ting
om sig selv.
Hvis der er noget man ikke udfylder, vil serveren modtage en tom streng.
Det nemmeste så bare at lagre denne tommme streng, uden at gøre noget ved
den. Jeg kender ingen argumenter for at gøre andet, herunder at putte null
i feltet.

--
Mvh.

Niels Andersen
(la nels. anersyn.)

---

Niels Andersen wrote:

> Hvis der er noget man ikke udfylder, vil serveren modtage en tom streng.
> Det nemmeste så bare at lagre denne tommme streng, uden at gøre noget ved
> den. Jeg kender ingen argumenter for at gøre andet, herunder at putte null
> i feltet.

At bruge null er datalogisk "den rigtige ting" (TM) at gøre. Det kan så
være lidt besværligt at teste for om strengen er tom og i givet fald
erstatte den med null-værdien, men mon ikke der findes faciliteter for
det i mySQL.

I Oracle er den tomme streng det samme som null hvilket ikke er helt
rigtigt datalogisk set, men meget bekvemt. Når man så modtager alle
data fra brugeren kan man bruge en helt almindelig insert, og alle
tomme strenge bliver automatisk lavet om til null's.

-Claus

---

Claus Rasmussen wrote in <agsf6o$qvn$1@sunsite.dk>:
> At bruge null er datalogisk "den rigtige ting" (TM) at gøre.

Okay. Den slags argumenter plejer jeg at tage til mig. :)
Jeg vil overveje det lidt mere for fremtiden.

> Det kan så
> være lidt besværligt at teste for om strengen er tom og i givet fald
> erstatte den med null-værdien, men mon ikke der findes faciliteter for
> det i mySQL.

Tjah, tjoh... Hvis det er MySQL-specifikt vil jeg nok passe på med at
benytte funktionen. Det kunne jo være at jeg pludselig skulle skifte til
PostGreSQL eller sådan noget. :)

> I Oracle er den tomme streng det samme som null hvilket ikke er helt
> rigtigt datalogisk set, men meget bekvemt.

Det lyder som en af de ting, som gør det nemmere mens man fiser rundt i en
rus af... "newbieness", og alligevel ikke fatter forskellen.
Og derefter er det et problem der hele tiden skal omgås. Argh argh...

--
Mvh.

Niels Andersen
(la nels. anersyn.)

---

Niels Andersen wrote:

> Claus Rasmussen wrote in <agsf6o$qvn$1@sunsite.dk>:
>> At bruge null er datalogisk "den rigtige ting" (TM) at gøre.
>
> Okay. Den slags argumenter plejer jeg at tage til mig. :)

Ok, så er her en lidt mere udførlig forklaring...

Et lille eksempel: Du har en tabel over personer og deres alder. Lad
os sige, at der er tre personer i tabellen. Den første er 39, den anden
er 40, men den tredje kender man ikke alderen på, så feltet er null.

Vil man finde gennemsnittet af personernes alder, bliver det besværligt,
hvis man ikke anvender NULL, mens følgende select til gengæld giver det
rigtige resultat uden videre bøvl:

select avg(alder) from tabel;

AVG(ALDER)
----------
39,5

Det skyldes at 'avg' og alle andre indbyggede funktioner kender til
NULL og ved hvordan den værdi skal behandles.

Det er en god ting, at vænne sig til at bruge NULL fra begyndelsen.
Så får du behandlingen af NULL ind på rygraden, så du ikke har pro-
blemer den dag, du /skal/ bruge NULL.

....

>> I Oracle er den tomme streng det samme som null hvilket ikke er helt
>> rigtigt datalogisk set, men meget bekvemt.
>
> Det lyder som en af de ting, som gør det nemmere mens man fiser rundt i en
> rus af... "newbieness", og alligevel ikke fatter forskellen.
> Og derefter er det et problem der hele tiden skal omgås. Argh argh...

Nemlig. Jeg har prøvet at stå i en situation, hvor den tomme streng
var ok at have som værdi, men jeg skulle også bruge NULL... Og så var
den feature lige pludseligt ikke så smart mere

-Claus

---

Claus Rasmussen wrote in <agsjsa$97i$1@sunsite.dk>:
>>> At bruge null er datalogisk "den rigtige ting" (TM) at gøre.
>> Okay. Den slags argumenter plejer jeg at tage til mig. :)
> Ok, så er her en lidt mere udførlig forklaring...

Heh, det var nu ganske seriøst. :)
Nogle gange kan konklusionen være nok i første omgang, så kan forklaringen
komme senere. :)

Men tak for forklaringen alligevel, så er jeg fri for at lede efter den
senere hen. :)

--
Mvh.

Niels Andersen
(la nels. anersyn.)

---

> Jeppe gemmer et 0, du gemmer en tom streng... Har I aldrig hørt om
> "DEFAULT etellerandet" i kolonnedefinitioner? : )

hehe, jow det var nu også det jeg mente.... ;)

Tak for svarerne ....
/Jeppe

---

Jeppe Vesterbæk skrev:
>
> Hvad er det bedste, enten benytte null-værdier, bare skrive 0 i feltet eller
> splitte min bruger-tabel ud over flere tabeller?

Jeg plejer at bruge NULL - med mindre, der er tale om en
sandt/falsk-kolonne - i så fald sætter jeg kolonnen til at være 0 som
standard, og så indsætter jeg 1, hvis værdien skal være sand. Jo, jeg
ved godt, at f.eks. PostgreSQL har en BOOLEAN-datatype, men jeg forsøger
at holde mig til SQL-standarden, så...

---

"Jeppe Vesterbæk" wrote:
>
> Hej
>
> Jeg er ved at opbygge en mySQL-database til brug til en php-side, jeg er ved
> at lave. Databasen skal blandt andet kunne indeholde oplysninger om
> registrerede brugere (dvs. bl.a. navn, adresse, email, icq osv). Det er dog
> ikke sikkert, at alle f.eks. har et icq-nummer, hvilket leder jeg frem til
> spørgsmålet:
>
> Hvad er det bedste, enten benytte null-værdier, bare skrive 0 i feltet eller
> splitte min bruger-tabel ud over flere tabeller?
>
> Jeg mener, at forskellige databasebøger, jeg har læst, ikke skriver meget
> pænt om null-felter, så dem ville jeg umiddelbart helst undgå. Det med at
> splitte tabellen op, så jeg f.eks. har icq-nummer og primærnøglen fra
> bruger-tabellen synes jeg er en lidt bøvlet løsning, da der er ret mange
> felter, hvor det er valgfrit om man udfylder. Det jeg er kommet frem til, at
> nok at jeg bare skriver "0" i felter der er "tomme".
>
> Kommentarer...?

NULL er en pseudo-værdi til at angive, at der mangler information.
Manglende information kan skyldes mange ting (vi kender den ikke, den
giver ikke mening (sidste menstrationsdata for en mand), den giver ikke
mening endnu (dødsdato) etc.).

NULL giver en række problemer, men de bliver ikke mindre af at du
opfinder din egen pseudo-værdi ved at benytte 0 i stedet for. Med mindre
du faktisk har en række gode argumenter *for*. Til gengæld bliver de
anderledes med det resultat, at du skal håndtere pseudoværdier på en ny
måde hver gang, frem for en gang for alle at lære at håndtere NULL.


--
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.