Jens Axel Søgaard wrote:
> Christian Iversen wrote:
>
>> Jens Axel Søgaard wrote:
>>
>>> Christian Iversen wrote:
>
>
>>>> Man bruger typisk NULL til at oplyse at et givent spørgsmål er
>>>> meningsløst, eller at informationen ikke er tilgængelig.
>>>
>>>
>>> Det er forresten interessant at læse C.J.Date og Darwens syn på NULL i
>>> SQL-databaser. Se for eksempel side 3 i
>
>
>> <
http://www.hughdarwen.freeola.com/TheThirdManifesto.web/Missing-info-without-nulls.pdf>
>>
>>
>> Det er egentlig ganske interessant læsning, men jeg er nu ikke helt
>> enig i
>> argumentationen. De mener at NULL er dårligt fordi det ikke giver
>> anledning
>> til at skelne mellem "vi ved at informationen ikke findes" og "vi kender
>> ikke informationen". Men _det_ skel kræver jo netop at udsagnet "vi kan
>> vide om informationen er utilgængelig eller ukendt" giver mening, og det
>> gør det jo ikke altid.
>
>
> Hvis det så bare var det. Som NULL er defineret i SQL kan "prædikater"
> pludseligt have tre! værdier: sand, falsk og null. Sammenenligninger,
> hvor null optræder giver altid null.
>
> X=X
> ---
>
> Sammenligningen X=X skulle man tro altid gav sand, men næ-nej
> hvis X er null giver X=X pludselig null.
>
> Da en relation er en mægde af tupler, kan man ikke komme ud
> for at t1=t2 for forskellige tupler i samme relation. Men
> er tuplerne
>
> navn pris
> t1 "tv" NULL
> t2 "tv" NULL
>
> ens? Tjah - da det ikke sandt at t1=t2 (det kræver alle alle
> attributter er ens, men NULL <> NULL) skulle man tro
> at t1 og t2 ikke er dubletter. Det er de så alligevel i SQL.
>
> p OR NOT p
> ----------
>
> Ovenstående booleske udtryk skulle man tro altid gav sand,
> men så heldig er man ikke i SQL. Hvis p skulle gå hen
> og give null, så giver ovenstående null.
>
>
> r JOIN r er ikke altid r
> ------------------------
> Tilstedeværelsen af null "ødelægger" også de fundemantale
> relationelle operatorer så som join. En relation r med
> en tupel indeholdende et null opfylder ikke at r JOIN r = r.
> Det betyder f.eks. at INTERSECT ikke længere er et specialtilfælde
> af JOIN.
>
> A=B og B=C medfører ikke at A=C
> -------------------------------
> Ja, hvad skal man sige.
>
>
> [Eksemplerne er taget fra C.J. Dates bog: "An introduction to
> database systems"]
>
>> Jeg tror jeg bliver ved med at bruge NULL et stykke
>> tid endnu, det er tilstrækkelig godt, og virker fint
>
>
> Men hvor ville det dog være godt, hvis SQL databaser rent faktisk
> var relationelle...
>
> Men det varer nok et årti eller to før der sker noget på den front.
>
>>> [Jeg kunne ikke finde "The last NULL in the coffin?" nogen steder]
>
>
>> God titel :)
>
>
> Ja - jeg blev helt nysgerrig efter at læse den.
>
ja undskyld mig, men for mig virker det som en logisk opførsel af systemet. Det
propagerer null'et alle de steder hvor det er indgået i en sammenligning, så man
nemt kan se om man (fejlagtigt) har lavet en forespørgsel hvor der indgik
værdier man ikke havde kendskab til. Inden for datalogien vil jeg mene det er en
meget praktisk strategi.
Hvis alternativet er at den fortier det vil svaret (som nu er forskelligt fra
NULL) jo højst sandsynligt være forkert, eller i hvert fald alene et gæt.
To prædikater som begge er sat til NULL er ikke nødvendigvis ens, da du ikke
aner HVAD de er. Derfor "evaluerer" udtrykket til NULL og sammenligningen kan
fortsætte højere op i syntakstræet indtil der bliver returneret.
Fejlen ligger i at se "NULL" som en tredje konkret værdi (når vi taler om
boolske udtryk). Tanken er en helt anden med NULL egenskaben.
Man kan sammenligne det med algebra med en ukendt størrelse x (af kategorien
NULL) i et stykke som ellers udelukkende har kendte konstanter.
2+17*3-x ~ ((2+(17*3))-x)
(17*3) = 51
((2+51))-x)
(2+51) = 53
(53-x) = y
Da vi intet ved om x ved vi heller ikke hvilken værdi y har (udover at det må
være 53 mindre end x, men det er ikke relevant i denne sammenhæng), derfor er
svaret bare "endnu en instans af typen NULL".