Re: So what's null then if it's not nothing?
Date: Thu, 24 Nov 2005 12:28:46 GMT
> 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.
Where it gets more interesting is if you throw the following at the RM
(Pick will have no trouble AFAICT).
Cheers, Frank. Received on Thu Nov 24 2005 - 13:28:46 CET