Re: So what's null then if it's not nothing?

Hugo Kornelis wrote:

> On Wed, 23 Nov 2005 01:09:56 GMT, Frank Hamersley wrote:
>
> >Hugo Kornelis wrote:
> >[..]
> >>
> >> Mind you, I don't *KNOW* it can, since I know nothing about Pick. But
> >> the description of Pick's data structure that DonR wrote (message-ID
> >> <1132350557.673092.92800_at_g49g2000cwa.googlegroups.com>) reminds me very
> >> strongly of XML. And in XML, it's easy to simply remove a "field" from a
> >> "row": in "<Person><Name>Hugo Kornelis</Name></Person>", there are no
> >> tags for birthdate, which clearly indicates that the value for my
> >> birthdate is absent in this piece of data.
> >
> >Is "<Person><Name>Hugo Kornelis</Name></Person>" the same as
> >"<Person><Name>Hugo Kornelis</Name><Birthday></Birthday></Person>"?
>
> Hi Frank,
>
> I don't think so.

I agree. They're not the same.

> I the first XML string, there is no Birthday attribute
> for me. It's missing. In SQL, this would be represented by NULL in the
> table, or my omitting the row if the birthday were stored in a seperate
> table.

Omitting the row sounds right. Using NULL is certainly wrong. The thing doesn't exist. Nor does <WhatYouDidLastNight/>. Using NULL for everything that doesn't exist would take up a considerable amount of storage space - like the size of the known universe and more.

> In Pick, this would (as I understand it) be stored by omitting
> the cell for Birthday.
>

In the first example, yes.

> The second XML string lists a blank birthday for me. That can't be
> stored in SQL, as it's strong typing prevents a date from being blank.

It should be represented by NULL. NULL is, after all, regardless of data type.

> The Pick data model appears to accept this (unless the DB engine checks
> before inserting the data), as does XML.

Correct.

>
> Best, Hugo
> --

Regards
Mike. Received on Wed Nov 23 2005 - 22:39:35 CET