Re: What does this NULL mean?

dawn wrote:
> Frank Hamersley wrote:
>

>>...

>> In fact, would it be possible given he
>>"knows" what makes a 5 star product, for him to be associated with
>>anything less?

I don't know the guy but from his writings I'd guess he is plenty wise enough to know that and he is certainly not afraid to publicly change his mind. A darned good critic and more besides because he looks at how results are obtained and is competent to assess that was done. And he has produced and designed at the internals level. I gather he started at a legendary company "Leo computers" which somebody told me was started by a supermarket owner who couldn't get what he wanted from ICL!

Suspect Date would never compare himself to Bertrand Russell but in this limited sphere, I can. What did Russell ever do except write a massive tome for the public that the public didn't read as well as criticize pretty much everything in human affairs? Well, what he did was make sense.

IMHO, the hominem stuff about Date is a poor show in this group. We should pay more attention to what is being said.

As for valid alternative theories, that's fine, but they need to be more than theoretically valid. They have to be amenable to common computers and scaleable as well. Nobody worth reading, including Date, ever said the RM is the be-all and end-all. Date is saying that it hasn't been done properly, YET. He gives lots of evidence to back that up, SO FAR.   Ebert is entertaining but not nearly as thorough as Date and his subject is very subjective, much more so than "databases.theory".

Personally, I'd like to read a movie review or wine column by Date if he wrote one. Doesn't mean I want to kiss him.

Cheers,
pc

>>>Similarly, if I read Date, it is often clear to me where it is I
>>>disagree.  If someone says "Date says ..." that does not mean I will
>>>agree with it (you might have noticed) but if I read what he wrote, I
>>>can typically figure out where my disagreements come in.  An exception
>>>would be when he starts out by defining a Relation the way he does in
>>>his Intro to Database Systems, 8e book.  It is so hard to find and
>>>follow the def that it was hard to care about anything based on it.
>>
>>Is it the same in 2e?

>>>>Personally my introduction to material produced by him was as an
>>>>undergrad when Intro to DB Systems (2nd Edition) was the course text.

>>>>It, I presume, is still considered a significant book but having picked
>>>>it up recently I came to the conclusion it is basically a catalogue of
>>>>preexisting material.

>>>It is a textbook, afterall, so if he could adequately capture the
>>>existing material there, that would be a good start, right?
>>
>>And FWIW I think even 2e was more than a good start.

>>>>Right place, right time if you like, in terms of
>>>>capturing Codd's Damascus event and a good presentation.  However the
>>>>genesis of his career was as an instructor not an architect or even an
>>>>engineer.
>>>>
>>>>Having read some of the free to air material attributed to him and his
>>>>freely associated with colleagues I have my doubts that he should be
>>>>accorded quite as much stature as perhaps is common today.
>>>
>>>I don't have problems granting him stature as one who influences the
>>>landscape, even if his works are not all things to all people.
>>
>>Thats OK by me.  I don't have any problem with him or his associates
>>"trying" to influence stuff, I'm just feeling slightly heretical about
>>the TTM direction.

>>>>To
>>>>illustrate is quote from page 9 of the "Missing Info without Nulls"
>>>>lecture notes presented by HD ...
>>>>
>>>>"And we have reduced the salary part of the database to the simplest
>>>>possible terms.
>>>
>>>One of my trigger words for Date's work (as well as others discussing
>>>the RM) is "simplest" -- that is a term about which there could
>>>certainly be a difference of opinion, even when working with
>>>mathematical theory.  What is simpler -- a square or 1 as the identity
>>>in multiplication?
>>
>>KISS is my guide!

>>>>Yes, some of the complicated queries get more difficult
>>>>now, because we might have to combine these tables back together again,
>>>>but the simple queries, such as 'How much salary does each person (who
>>>>has a known salary) earn?' and 'Who earns no salary?' become trivial."
>>>>
>>>>So trivial remains trivial and complicated becomes near impossible.
>>>>This type of progress I think conveys your point comprehensively Pete!
>>>
>>>I agree.
>>>
>>>
>>>>>People who construct database systems but do not maintain
>>>>>them, or have not maintained them for more than a few years,
>>>>>will never understand that the greatest entry point of nulls into
>>>>>the database is during change.
>>>
>>>But do not confuse the introduction of NULLS into the data with the
>>>need to use a 3VL.
>>
>>Not sure of your thrust here - would you care to elaborate?

>>>>Ne'er a truer word wrote!  Personally I try to manage backfilling (to
>>>>simplify new queries dealing with old data) where possible without
>>>>polluting history, but of course that is not always going to be possible.
>>>>
>>>>
>>>>>Change management or schema evolution is not adequately
>>>>>addressed by Date et al, however by the time they set forth
>>>>>the processes covered under this subject, it will become very
>>>>>apparent that the NULL will never be rationalised away, and
>>>>>it is better to therefore appropriately manage its identification,
>>>>>its existence and its resolution interactively.
>>>
>>>I agree that Date does not address change management adequately.  He
>>>doesn't seem to "feel it in his bones" as those who have lived there
>>>do.  There will always be attributes where a lack of a value is a valid
>>>"value" -- the question is whether to treat it as a value or not within
>>>the logic system.  Treating it as a value, with valid operations where
>>>useful, has many advantages over treating it as a value to the internal
>>>system that reflects itself as a lack of a value to the logic system,
>>>which needs to resolve to values back to the user.
>>
>>Perhaps he is trying to keep the domain of interest manageable. However
>>I like Pete and yourself it seems feel this is far too significant an
>>issue to be left out of any grand plans.

>>>>Not adequately, or not at all?  I haven't yet (and given my views above
>>>>am unlikely to ever) shell out for their dissertations on Temporal
>>>>affairs, but I wonder how they might approach the issue when the schema
>>>>itself has temporal variability.  I suspect to apply this to SQL-D if it
>>>>ever materialises would lead to an exponential number of relvars with
>>>>untold amounts of information buried in the metadata.  Of course for an
>>>>inaugural novelty (tautology intended) I could be wrong :-).
>>>
>>>Perhaps we can let SQL fade off into the sunset before then (while, of
>>>course, having to maintain and incredible amount of SQL code).  Cheers!
>>> --dawn
>>
>>Here we diverge - low roads, high roads, whatever - I personally don't
>>relate to SQL as being the problem.

>> Its just a tool, perhaps often used
>>by the wrong hands.