Re: So what's null then if it's not nothing?
Date: 25 Nov 2005 02:32:04 -0800
Message-ID: <1132914724.414469.36610_at_g49g2000cwa.googlegroups.com>
Sorry I missed this earlier Alexandr.
Maybe I saw it and didn't want to acknowledge the fact that I'd seen it. Anyway - it managed to slip my mind for a while.
Alexandr Savinov wrote:
> michael_at_preece.net schrieb:
> > Alexandr Savinov wrote:
> >
> >>I wanted to say that
> >>- assigning null value, and
> >>- deleting a link record
> >>is one and the same (in the context of our discussion).
> >
> >
> > In Pick you would set the record to null and write it back. That
> > records the fact that the thing is empty - which is entirely different
> > to recording the absence of the thing.
>
> What is the difference between empty thing and a thing that does not
> exist (or absent thing)? (In Pick)
>
Excellent question.
In Pick you can delete or set to null an Item, a MultiValue or a SubValue without a problem - generally. Deleting an Attribute is generally a no no. This is, in my opinion, a deficiency in Pick as it is most widely used. The Attribute number in an Item is significant 999,999 times out of 1,000,000. Consider an Item to be a delimited string, with >=0 delimited Attributes, which can contain >=0 MultiValues, which can contain >=0 Subvalues. If you delete an Attribute, you mess up the structure of the "tail" of the Item to which it belongs. The File the Item belongs to will usually have a Dictionary with metadata relating to each Attribute position. There is generally no metadata for the position of MultiValues or SubValues. Note that these are general rules - as would apply to the vast majority of Pick databases out there. Also, if either a MultiValue or a SubValue is part of an association, then you cannot safely delete a single member of the association, without deleting all of its associated members. As I said in my first sentence though, you can go ahead and delete an Item or a non-associated MultiValue or SubValue with impunity - if the data ceases to exist, or becomes absent. Obviously, there are ways to structure the data so that you avoid these issues. Pick is very flexible. It all comes down to how you use it. To answer your question straight though - very often, null is used to represent missing data that cannot be safely deleted in Pick. Not as it should be - just as it is in the vast majority of cases.
> For me empty thing is a thing with all fields nulls but with non-null
> identifier.
Yes - this is familiar to me too, although, strictly speaking, I would not call something null if it contained anything at all - and that includes more than one null thing. It would typically be an Item with null Atts, and/or an Att with null MVs and/or an MV with null SVs. Incidentally, one Item per file can have a null identifier - although this is considered bad practice.
> In this case it exists only as identity but not as an
> entity.
Although - it can exist as an entity containing entities which contain empty things. In any realistic scenario this is most unlikely to be valid data. Could be though.
> As a result it is invisible in any dimension (no report or query
> will retreive this record).
Not so in Pick. Null items, even null items which have null identifiers, can be reported or enquired upon - or excluded from reports or enquiries.
> The only way to get it consists in using its
> identifier. Are there other interpretations?
We can select data and specify whether we want to include or exclude nulls for any fields as part of the selection criteria and/or as part of the output. Nulls will appear as blanks in the formatted output (unless you want to do something else - format them in some way). They're data - they're just empty.
Best regards,
Mike.
PS. That was difficult! Good on ya. Received on Fri Nov 25 2005 - 11:32:04 CET