Re: What does this NULL mean?
- From: Frank Hamersley <terabitemightbe@xxxxxxxxxxx>
- Date: Fri, 16 Dec 2005 06:39:50 GMT
dawn wrote:
Frank Hamersley wrote:
dawn wrote:
Frank Hamersley wrote:
mountain man wrote: [..]
Theorists like Date who think the null should be rationalised out of existence have no demonstrated understanding of the database change management environment, and specifically the management of schema evolution and its consequences in regard to the generation of nulls.
Just picking up on a minor point that has been front of mind for some while - who in this place considers Date to be a credible theorist and especially to be accorded stature commensurate with a luminary?
[..] Vale Ebert!
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?
I must be far younger than you -- I don't have 2e ;-) If you have it, I would really, really like to know what you can glean as the definition of a Relation from the text.
Can provide if you have some pointers where to look...I don't have time to read the whole tome just at this moment ... Xmas excess beckons!
Personally my introduction to material produced by him was as an undergrad when Intro to DB Systems (2nd Edition) was the course text.
Oh, there were DBMS products when you were an undergrad? nevermind.
Various ISAM stuff from what I recall. SQL nope!
^^^^^^^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.
I am pretty sure he has made significant revisions between 2d and 8e, but it is still a text book.
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.
8e wasn't an afternoon read.
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.
only slightly? Embrace your heresy. One thing that I think is very important is a change in how the RM is taught at the undergrad level. It is taught as if it was handed to us as truth by God herself. There
</OT>Heh heh - perhaps that explains the state of affairs in the world. :-)<OT>
are many ways to model propositions for data processing, the RM being only one of them (and not the most flexible IMO).
Eye of the beholder stuff perhaps!
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!
Of course. But here is an exaggerated argument in relational theory: We can model propositions as Relations. We can model propositions as Di-Graphs. Relations are simpler than Di-Graphs. Therefore we must model propositions as Relations.
Can you find the flaw in that (non-mathematical) argument?
Nope - not enough spare time and far too sleep deprived at the moment but if pushed to guess I suspect one, if not all, of your assumptions are faulty.
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?
In my interchange with Hugo in another thread (IIRC) you can see that I work with nulls and a 2VL. In fact, if you use a programming language and you collect data from a UI, it is very likely that you deal with nulls and a 2VL. It rarely makes you blink, it is so straightforward.
Do you commonly perform the relational operations in the application layer?
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.
Pete and I end up with quite analogous but rather opposite approaches. I practically give up on database-specific code and put everything in a db-independent system (set of applications), eliminating SQL from the mix altogether. Pete tries to get everything into the DBMS tool (thereby making it more database-specific, but minimizing use of non-SQL programming languages).
I guess you just answered my previous question! Do you also avoid the ocean because of the sharks? Where I live it is actually a serious question, but I would relate SQL moreso to a whale - quite harmless* unless you do something silly and get squashed like a gnat.
* notwithstanding those yachts that have lost a keel in mid ocean.
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.
The RM is the problem and SQL compounds the problem.
A pity you are intransigent on that point. Personally I don't see Pick as a problem at all, although I am unlikely to rush out an implement it in my next engagement.
Its just a tool, perhaps often used by the wrong hands.
It is a flawed tool (as they all are) that attempts to align with a model that was not made to have the simplest interface for a human to use, but rather to have a simple internal structure. The language aligns more with that internal structure than with a human being. This is just one opinion, of course. --dawn
Funny - I just don't find it a challenge in the negative sense! It can be an intellectual challenge to get the outcome needed but that says more about me than SQL. Sure there are few cases where the syntax could be optimised (UPDATE FROM is a hot candidate) but as an experienced user it presents no material problem.
Cheers, Frank. .
- References:
- What does this NULL mean?
- From: Eric Junkermann
- Re: What does this NULL mean?
- From: mountain man
- Re: What does this NULL mean?
- From: Frank Hamersley
- Re: What does this NULL mean?
- From: dawn
- Re: What does this NULL mean?
- From: Frank Hamersley
- Re: What does this NULL mean?
- From: dawn
- What does this NULL mean?
- Prev by Date: Re: What does this NULL mean?
- Next by Date: Re: So what's null then if it's not nothing?
- Previous by thread: Re: What does this NULL mean?
- Next by thread: Re: What does this NULL mean?
- Index(es):
Relevant Pages
|
