All hail Bob!
Jay Dee
Newsgroup: comp.databases.theory
I came across:
Subject: Entity Overlap and Relationships
The first post in the thread was:
From: GB
1 1. What is the "industry best practice" in the following
2 situation:
3
4 Say there are 3 types of entities {Entity1, Entity2,
5 Entity3}
6
7 Each Entity type has unique attributes and similar ones.
8
9 For the attributes that are unique to each Entity it is
10 easy (either they are in the table with the Entity or in
11 the case of a one-to-many relationship there is a table
12 related only to that Entity).
13
14 In the case where there are similar attributes (i.e. each
15 Entity has multiple addresses - all of the same form {
16 addressline1, addressline2, city, state, zip, etc })
17 what is the proper way to handle this? I was thinking
18 of creating the following tables for each entity:
19 Entity1Address, Entity1Phone, Entity2Address, Entity2Phone,
20 Entity3Address, Entity3Phone with the Address and Phone
21 tables all the same but related only to the relevant Entity
22 table but something rubs me the wrong way here...
23
24 2. What is the best way to handle people-people
25 relationships (from a schema perspective - I can see the
26 sarcastic remarks now)? Has anyone solved this problem of
27 how to store {father, son, uncle, friend, etc.}? Did you
28 have to set up a trigger to update the table to include the
29 son relationship entry if the father relationship was added
30 for instance? Or would you just store the "parent" and
31 "child" title for the relationship, in this case "father"
32 and "son" then the related unique ID's for the people with
33 the relationship?
"Oh, boy," I thought, "this is going to be entertaining."
Lines 4 and 5 set us up for a "general" situation. Line 7
opened the gates. Line 9 said this would be easy, except...
Lines 11 and 12 made me flinch.
"Uh, oh. Here's that 'Entity relationship' thing, again, this
time masquerading as "...a table related only to that Entity."
(I've had to train myself from making the "I know what was
meant despite what was written' mistake. Again.)
Without wasting time, the poster launched into a pseudo-design
and started slinging attributes and tables and Entities with
meaningful names about while revealing his thought processes
to the world.
Line 24 seems to pose a general question to the general
situation presented in the first two dozen lines. After reading
the follow-on question starting on line 26, I thought, "Would
the poster be happy with a simple 'Yes?' Probably not."
The soon-forthcoming presumption that the evasive general
solution might involve a "trigger" which maintained a
"relationship entry" confirmed what I suspected may have
caused the poster to turn to the newsgroups with such a trivial
problem: "Too many tools, not enough knowledge."
The first reply was spot-on advice. And line 3 contains a bit
of prophecy that, once you watch this newsgroup for a while,
really isn't all that prescient.
From: BB
1 With all due respect, the answers to your questions
2 will depend on the myriad requirements you have not
3 mentioned. Anyone who pretends to have answers is a crank.
The OP politely thanked BB for his response, ignored it,
and pressed on with more magic dust: GUIDs!
*sotto voce* Do you know how many problems GUIDs have
solved? Here's a clue: the value's less than one.
From: GB
1 Thanks for the response, I really appreciate it even though
2 I still might need to flesh out my problem a bit more.
3 I guess my rephrased question is this: if I use a GUID as
4 the ID for each Entity regardless of EntityType, should
5 I have one table like EntityAddress that has an EntityID
6 (GUID) column which relates to all three Entity Tables?
7 Thus all Three Entity Tables would use the same address
8 table?
Another optimistic contributor tried to get the original poster
back on track. Without sounding dogmatic, and quietly restating
the fact that too many requirements are still unstated, JH
suggested a strategy for discovering a solution.
From: JH
1 You first of course need to establish whether that
2 actually correctly models the situation. For example, is
3 there really such a concept of *the* address of an entity
4 (or *the* set of addresses) or could this depend upon
5 the context (working address, billing address, shipping
6 address, private address, et cetera). After you've
7 established this you then have to think about what is
8 the more efficient option. What are the typical queries
9 that will be asked. What integrity constraints can the
10 DBMS maintain and do you want them maintained? All these
11 things might might play a role in deciding what is the
12 best option, and I probably forgot a few.
Words like "first" and "after" have well-known meanings.
The poster didn't get it. He tries to convince us -- and,
perhaps, himself, that he has but, as we shall soon see, the
more he noodles the question the more obvious it is that he
has already flung himself into an abyss.
From: GB
1 Thanks Jan! I think I understand in that the design should
2 mimic the *carefully* thought out business requirements.
3 In this case, each Entity type will likely have multiple
4 addresses but the more I noodle on it I am thinking of
5 doing what you rec'd in terms of using a fixed set of
6 addresses for each entity type except for people. I will
7 likely run into the situation that the Entity Type that
8 tracks people will have more than a "forecastable" number
9 of addresses since most of the firm's clients (high net
10 worth individuals) seem to have a multitute of addresses
11 (winter home, summer home, beach home, hawaii home -
12 nice problem to have I suppose). As for the Business type
13 entities, they will likely have less but more standardized
14 addresses (sales office, ship to, invoice to, etc.).
15 The third type is kinda like a VAR and has it own set
16 of addressing issues. I sincerely appreciate your post
17 and it has kept me thinking. I just hate getting further
18 down the road and having to change something after I have
19 migrated data over!
The designer has noodled some more requirements into the mix:
"multiple addresses" and a "fixed set of addresses" and
"more than a 'forecastable' number of addresses" indicate a
design-in-process that will soon need a capability-enhancing
retrofit.
And, lookity here! On lines 6 and 12 we learn that Thing One
and Thing Two are people types and Business types. On line 15:
Thing Three is a kinda type which "has it own set of addressing
issues."
not so *sotto voce* If "addressing issues" don't distinguish
a "type" then I don't know what would! What is a type,
anyway?
My turn at a prediction: this project isn't going to get very
far "down the road [before the designer will have] to change
something after [he has] migrated the data over." Too, I'm
sure that the designer believes the impact of such a retrofit
will be mitigated because, it seems, work is underway using a
design that will have to be enhanced to accommodate those other
"addressing issues."
Speaking of which: BB's prophecy has been fulfilled! Help is
on the way!
From: DW
1 I'll give this first one a shot. If I am understanding
2 your question, you would likely want an Address table
3 with a generated key. Then each of your Entity1-3 tables
4 would have an attribute that is a foreign key to the
5 Address table.
6
7 I wouldn't typically do the same thing with phones, even if
8 storing PhoneType PhoneNumber pairs, as there is an ongoing
9 cost for such designs. But if you need to store multiple
10 phones for an Entity (and are saddled with a SQL-DBMS),
11 then that would be OK. You might instead have an attribute
12 for BusinessPhone, HomePhone, and MobilePhone for each
13 Entity. You are out of luck if you have two business
14 phone numbers then, but this is often sufficient and I
15 suppose you could add a catch-all OtherPhone. You will
16 obviously need to know your precise requirements.
Wow! Foreign keys. How did we miss that? And new entities.
I think. Phones? Of various types? And typed attributes
for Entities? Or are those attributes to hold values of
certain types? Except for the "catch-all Other?"
Hmm. I'm having trouble keeping up: are those other types or
other values? And where, exactly, does this design run out
of the luck referred to on line 13? When the number of values
of type BusinessPhone exceeds one?
I'm going to keep an eye on this discussion to see how my
predictions work out...
-----
What's the point of this oblique rant?
While BB's blunt replies to and comments on other posts
jolted me, I've come to feel that he has faced and embraced a
worthwhile truth: being polite is sometimes a greater barrier
to communication than being rude.
If someone tells you that you're a rock-headed moron, you
just might be. For some of those, the next obvious question is,
"Do I want to stay that way?"
Roy Hann
news:5fZ1g.11150$P2....@tornado.ohiordc.rr.com...
> If someone tells you that you're a rock-headed moron, you
> just might be. For some of those, the next obvious question is,
> "Do I want to stay that way?"
Amen to all that! (And I have been on the receiving end. I won't forget
THAT lesson.)
Roy
David Cressey
>
> What's the point of this oblique rant?
>
> While BB's blunt replies to and comments on other posts
> jolted me, I've come to feel that he has faced and embraced a
> worthwhile truth: being polite is sometimes a greater barrier
> to communication than being rude.
>
The question then becomes, how do you confront someone's ignorance without
being rude to the person?
This is made more difficult by the fact that we have been trained to be
ashamed of our own ignorance, while being light hearted about our own
stupidity. Witness the proliferation of books "for Dummies" (a reference
for the rest of us).
I'm one of us, but I'm not one of the rest of us (in that sense). I hope I
share that with most of the readers in this group.
> If someone tells you that you're a rock-headed moron, you
> just might be. For some of those, the next obvious question is,
> "Do I want to stay that way?"
>
Or you might just be ignorant, which is not the same thing as "rock headed
moron". The problem that people who know something often have is how to
deal with the "invincibly ignorant" person.
What I would wish from someone like BB is that he could, by now, offer links
to websites that develop the ideas in proper detail, and offer a positive
alternative. I refuse to believe that no such websites exist, or that BB
doesn't know of any of them.
In short, rudeness, by itself, accomplishes nothing.
Roy Hann
news:4Z12g.1172$Cc.510@trndny07...
> In short, rudeness, by itself, accomplishes nothing.
If the alternative is tortuous, endless, and increasingly forced civility,
then I strongly disagree. There comes a point when someone has had their
full turn in the spotlight and they need to be told to pipe down. Rudeness
is frankly welcome at that point (though hate-mongering is not).
Roy
Bob Badour
> "Jay Dee" <ais0...@aeneas.net> wrote in message
> news:5fZ1g.11150$P2....@tornado.ohiordc.rr.com...
> -----
>
> Or you might just be ignorant, which is not the same thing as "rock headed
> moron". The problem that people who know something often have is how to
> deal with the "invincibly ignorant" person.
"There is no stopping the invincibly ignorant. - DT"
> What I would wish from someone like BB is that he could, by now, offer links
> to websites that develop the ideas in proper detail, and offer a positive
> alternative. I refuse to believe that no such websites exist, or that BB
> doesn't know of any of them.
>
> In short, rudeness, by itself, accomplishes nothing.
I could point you to the papers Lee Fesperman publishes on his site at
http://www.firstsql.com/issues.shtml, and I could point you to
http://www.thethirdmanifesto.com/, and I could point you to Fabian
Pascal's site at http://www.dbdebunk.com/
However, those links would not substitute for a proper education on the
subject. For that, at a minimum, one would have to read a number of books.
For those whose goal is to use database management systems, I suggest
one can make a very good start at the book list on Fabian's site:
http://www.dbdebunk.com/books.html
Date's _Introduction ..._ is comprehensive. Fabian's book is good for
those who already know a bit of SQL or some of the RM. _The SQL
Standard_ will be less useful to most people.
The links and books would do nothing at all for the sorts of folks who
might contribute at the level of a Jan or a Vadim.
Bob Badour
> One day, while perusing
>
> Newsgroup: comp.databases.theory
>
> I came across:
>
> Subject: Entity Overlap and Relationships
>
>
> The soon-forthcoming presumption that the evasive general
> solution might involve a "trigger" which maintained a
> "relationship entry" confirmed what I suspected may have
> caused the poster to turn to the newsgroups with such a trivial
> problem: "Too many tools, not enough knowledge."
>
> The first reply was spot-on advice. And line 3 contains a bit
> of prophecy that, once you watch this newsgroup for a while,
> really isn't all that prescient.
>
> From: BB
>
> 1 With all due respect, the answers to your questions
> 2 will depend on the myriad requirements you have not
> 3 mentioned. Anyone who pretends to have answers is a crank.
>
> The OP politely thanked BB for his response, ignored it,
> and pressed on with more magic dust: GUIDs!
>
> *sotto voce* Do you know how many problems GUIDs have
> solved? Here's a clue: the value's less than one.
>
> Another optimistic contributor tried to get the original poster
> back on track. Without sounding dogmatic, and quietly restating
> the fact that too many requirements are still unstated, JH
> suggested a strategy for discovering a solution.
>
> From: JH
>
> 1 You first of course need to establish whether that
> 2 actually correctly models the situation. For example, is
> 3 there really such a concept of *the* address of an entity
> 4 (or *the* set of addresses) or could this depend upon
> 5 the context (working address, billing address, shipping
> 6 address, private address, et cetera). After you've
> 7 established this you then have to think about what is
> 8 the more efficient option. What are the typical queries
> 9 that will be asked. What integrity constraints can the
> 10 DBMS maintain and do you want them maintained? All these
> 11 things might might play a role in deciding what is the
> 12 best option, and I probably forgot a few.
>
> Words like "first" and "after" have well-known meanings.
What I don't understand is: Why isn't this topic called "All hail Jan!"?
All I did was warn someone against listening to cranks who pretend to
have solutions without knowing requirements. Jan, at least, provided
pointers on how to flesh out the requirements.
> My turn at a prediction: this project isn't going to get very
> far "down the road [before the designer will have] to change
> something after [he has] migrated the data over." Too, I'm
> sure that the designer believes the impact of such a retrofit
> will be mitigated because, it seems, work is underway using a
> design that will have to be enhanced to accommodate those other
> "addressing issues."
There are other possibilites. There is always the small chance, like a
lightning strick or Superball lottery win, that the resulting design
will actually match all of the requirements that were never considered.
In this case, the person will have an ideal design and will no doubt
eagerly proclaim to the world that he has solved all their problems.
In this situation, there is a high probability he will become a
consultant where he can earn a lucrative fee for repeating the design
and then move on before the client has to deal with the headache of
implementation.
There is of course a much, much larger chance that after the database is
populated with data and the applications are all written and rolled out
that the person will discover that some important users will actually
want to see some reports based on the data. At this time, there is the
very high chance of complaints due either to incorrect results, delays
and difficulties writing correct reports, or performance issues.
In this situation, there is a high probability he will decide that
normalization is the cause of all the world's ills. He can then become a
consultant and earn a lucrative fee by telling people that the
consultant who designed the database messed everything up by
overnormalizing or failing to denormalize. Take your pick.
Neo
:) This is easy. Just demonstrate it. For example, if someone says the
following data (ie judge example) is difficult in RMDBs but easy in Db
for Dummies, just post the script to do the equivalent so that others
including the dummy can verify it. Verification is the key.
JOG
Clearly it is not easy if the given person refuses to be receptive to
the arguments presented to them.
http://members.aol.com/intwg/antiprocess.htm
As an example, you keep asking people to post SQL, when it is clear
that the onus is not on others to refute you, but rather on you to
convince them. If one cannot do this it should be back to the drawing
board.
Neo
:) The worth-while-ness of such a "truth" is dubious if it only works
"sometimes". It seems you are making a preassumption which may need
verification. What is the preassumption?
JOG
I often feel like I'm getting a free education from Jan's posts. Long
may it last. If I manage to catch him at a conference I will buy him a
pint.
paul c
> ...
> What I don't understand is: Why isn't this topic called "All hail Jan!"?
If 'topics' were relvars it might well be of a sort, assuming the
hero-worshippers are the CWA complement of the ad hominem crowd.
p
Neo
>> :) This is easy. Just demonstrate it. For example, if someone says the following data (ie judge example) is difficult in RMDBs but easy in Db for Dummies, just post the script to do the equivalent so that others including the dummy can verify it. Verification is the key.
> Clearly it is not easy if the given person refuses to be receptive to the arguments presented to them.
:) Sure it's easy, just backup your presented arguments with something
verifiable. For example, if a child argues that a knife isn't sharp,
even after presenting theoretical arguments such as it is made out of
1020 stainless steel and very thin on one edge, then actually
demonstrate that it is by slicing a very ripe tomato. Ultimately
verification, not end-less argumentation is the key.
> http://members.aol.com/intwg/antiprocess.htm As an example, you keep asking people to post SQL, when it is clear that the onus is not on others to refute you, but rather on you to convince them. If one cannot do this it should be back to the drawing
board.
I have already shown that my car can run a never before tested track in
10 seconds. Now you want me to get in your car (you being Richard Petty
at his pinnicale, having demonstrated to be the fastest car driver in
the world) and show you it can't? Now suppose, I take your car for a
lap and it either comes in at 12 seconds or worse yet never makes it
around the track, would you believe the results? Or would you want to
jump in the car and prove it otherwise by yourself?
If you say that you would believe my results, then here is my run:
CREATE TABLE T_Thing (ID, Name);
INSERT INTO T_Thing (1, judge);
It didn't even make it around the track, so I can't report a time for
comparison.
How will you realize that your car actually might not be able to go
around this track without some accidents, until you (Richard Petty,
King of the Hill) give it your best shot?
Marshall Spight
Clean Water Act?
California Waterfowl Association?
Searching got me nothing better than the above.
Marshall
Neo
Let see if I can emulate Bob Badour and verify Jay Dee's thesis :)
JOG, you are a FUCKING MORON! You haven't a CLUE. You have me waste 35
FRICKIN minutes reading some BULLSHIT about skeptics and paranormalist
debating things that only exist in they CAVERNOUS SKULLs that neither
can verify? You mean your less than PEA-SIZED BRAIN can't distinguish
between the those type of debates and the ones here?
Jay Dee, did it work? Or was there some preassumption that you failed
to state, which itself may need verification.
David Cressey
"Roy Hann" <spec...@processed.almost.meat> wrote in message
news:rZednZZhOMp...@pipex.net...
Telling someone to pipe down isn't necessarily rudeness. Moderators do it
all the time.
Personal insults and deprecation are not helpful in this activity.
Bob Badour
I think it stands for the closeted word ascension or something like that.
Marshall Spight
> Marshall Spight wrote:
> >
> > Clean Water Act?
> > California Waterfowl Association?
>
LOL. Got it; thanks. I usually think of that last word as
"hypothecary",
but if he had said "CWH" I probably still wouldn't have gotten it.
Marshall
JOG
Sigh, you are embarrassing yourself again. Don't you owe someone $1000?
Marshall Spight
>
> Let see if I can emulate Bob Badour and verify Jay Dee's thesis :)
>
> JOG, you are a FUCKING MORON! You haven't a CLUE.
No, no, no. Bob would never resort to all-caps.
Marshall
Neo
:) Now proving that woooould turn to be like one of those discussions
described at members.aol.com/intwg/antiprocess.htm
> Don't you owe someone $1000?
:) Actually more than $1000 according to my calculations but not for
the reason you are probably thinking.
Neo
.
> No, no, no. Bob would never resort to all-caps.
:) Of course you are correct, but I thought I try to improve upon Bob's
implementation. It is a trait inherent to techies. Did I muck up his
methodology?
Neo
Actually what I meant by my prior polite comments and questions is: If
you have come to feel that way then you are a BIGGER FUCKING MORON than
Bob Badour.
Gene Wirchenko
Oh, how cute. First, it tried to speak DBese and failed badly.
Now, it is trying swearing.
Paraphrasing Sam Clemens, you have the words but not the tune.
Sincerely,
Gene Wirchenko
Neo
:) Sorry but I find your response to be antiprocess-like and thus
refuse to engage it any further. For details see
http://members.aol.com/intwg/antiprocess.htm
Gene Wirchenko
My lucky day.
Sincerely,
Gene Wirchenko
Neo
>> :) Sorry but I find your response to be antiprocess-like
>> and thus refuse to engage it any further. For details see
>> http://members.aol.com/intwg/antiprocess.htm
> My lucky day.
Actually what I meant by my prior polite comment was: Gene you are the
BIGGEST FUCKING MORON, even bigger than Jay Dee and Bob Badour put
together.
Jay Dee
You certainly have demonstrated something. For me, at least, the fog of
uncertainty is lifting.
Thank-you!
mAsterdam
Your and Bob's posts are very much alike. Boring.
At first you treated most readers of cdt as morons by repeating the same
blind spots over and over again, Bob simply picked out a few people who
are relatively ignorant in his expertise area, called them names and
actively blocks their communication at cdt.
Boring and sickening.
Suddenly you turn out to be able to actually read replies,
and Bob turns out to be able to actually contribute. Great.
I'm not an expert in what you and Bob are aiming for.
Yet I think I have to say some valuable on topic things to both of you.
I won't until I notice improvement in your showing respect.
Neo
> to state, which itself may need verification.
You certainly have demonstrated something. For me, at least, the fog
of uncertainty is lifting. Thank-you!
:) But now I am not sure if your just being polite... Anyways my
apologies for the language in this thread and I hope no one took me too
seriously. Adios Amigos!
Bob Badour
> I'm not an expert in what you and Bob are aiming for.
> Yet I think I have to say some valuable on topic things to both of you.
>
> I won't until I notice improvement in your showing respect.
I'll live. If you are going to wait until I show respect to
self-aggrandizing ignorants, you might as well just add me to your
killfile now.
It will save you much time.
mAsterdam
I don't have a killfile.
I would appreciate it if you would add the people you
are stalking to yours.
Bob Badour
Stalking? You've bought the self-aggrandizing ignorant's propaganda.
They have been added to my killfile for ages. I only see what they write
when somebody else excerpts it.
mAsterdam
> mAsterdam wrote:
>
>> Bob Badour wrote:
>>
>>> mAsterdam wrote:
>>>
>>>> I'm not an expert in what you and Bob are aiming for.
>>>> Yet I think I have to say some valuable on topic things to both of you.
>>>>
>>>> I won't until I notice improvement in your showing respect.
>>>
>>>
>>> I'll live. If you are going to wait until I show respect to
>>> self-aggrandizing ignorants, you might as well just add me to your
>>> killfile now.
>>>
>>> It will save you much time.
>>
>>
>> I don't have a killfile.
>>
>> I would appreciate it if you would add the people you
>> are stalking to yours.
>
>
> Stalking? You've bought the self-aggrandizing ignorant's propaganda.
Yes, stalking. It doesn't matter wether it's replied to or not.
That is (just) a formal (a.k.a. syntactic) excuse.
> They have been added to my killfile for ages. I only see what they write
> when somebody else excerpts it.
On my list (ordered, by definition) of self-aggrandizing idiots you rise.
Bob Badour
Your loss then. I really suggest you switch to a useful newsreader.
Personally, I use Netscape Mail & Newsgroups, but I am sure lots of
other newsreaders have killfiles.
mAsterdam
Ah! Let's rephrase. My killfile is empty. You did not understand that?
Pity. Pity you.
mAsterdam
Funny? Yep. Nevertheless, the closed world assumption marks a
paradigmatic boundary. (Pls google before asking :-)
mAsterdam
You snipped this, why?:
> Stalking?
mAsterdam
You snipped this, why?:
> Your and Bob's posts are very much alike. Boring.
>
> ... Bob simply picked out a few people who
mAsterdam
BTW why did you snip whitout notification?
Bob Badour
Uh oh! Now we are getting awfully close to the constructivist
hermeneutical seal--we don't want to break that one open.
Bob Badour
Sorry. "Not exists" and "exists but empty" seem like a logical
difference to me.
Bob Badour
> Bob Badour wrote:
>
>> mAsterdam wrote:
>>
>>> I'm not an expert in what you and Bob are aiming for.
>>> Yet I think I have to say some valuable on topic things to both of you.
>>>
>>> I won't until I notice improvement in your showing respect.
>>
>> I'll live. If you are going to wait until I show respect to
>> self-aggrandizing ignorants, you might as well just add me to your
>> killfile now.
>>
>> It will save you much time.
>
> You snipped this, why?:
I found it irrevant.
Bob Badour
I do that all of the time.
Bob Badour
> mAsterdam wrote:
>
>> Bob Badour wrote:
>>
>>> mAsterdam wrote:
>>>
>>>> I'm not an expert in what you and Bob are aiming for.
>>>> Yet I think I have to say some valuable on topic things to both of you.
>>>>
>>>> I won't until I notice improvement in your showing respect.
>>>
>>>
>>> I'll live. If you are going to wait until I show respect to
>>> self-aggrandizing ignorants, you might as well just add me to your
>>> killfile now.
>>>
>>> It will save you much time.
>>
>>
>> You snipped this, why?:
>
Duh! Typo: "irrelevant"
mAsterdam
Break it if you can.
BTW you don't have to google for "hermeneutical" (mostly harmless :-).
mAsterdam
Now this is new to me. Not.
Please explain in detail what it is, exactly,
what you are apologizing for.
mAsterdam
Bad habit.
mAsterdam
>
> I found it irrevant.
Sneeeky (I don't care for typos unless they confuse me.
Bob Badour
For your apparent confusion.
mAsterdam
Which? You mean between "I don't have a killfile" and "my killfile is
empty"? HAHAHAHAHA
Bob Badour
No, between "You" and "?"
mAsterdam
Yep. You have succeeded in getting me confued.
Now please explain (as I asked, in detail) what it is you are
apologising for.
mAsterdam
> ...You've bought the self-aggrandizing ignorant's propaganda.
> when somebody else excerpts it.
self-aggrandizing is your favourite adjective, it seems.
mAsterdam
Your are rising.
mAsterdam
>
> Duh! Typo: "irrelevant"
>
>> I found it irrevant.
I understood. Now quit stalking, ok?
David Cressey
"Bob Badour" <bba...@pei.sympatico.ca> wrote in message
news:the2g.63938$VV4.1...@ursa-nb00s0.nbnet.nb.ca...
Bob,
Please add me to your killfile.
That way, I can excerpt someone else's reply without drawing a comment from
you.
David Cressey
"mAsterdam" <mAst...@vrijdag.org> wrote in message
news:44498707$0$31637$e4fe...@news.xs4all.nl...
> Which? You mean between "I don't have a killfile" and "my killfile is
> empty"? HAHAHAHAHA
In the context of a discussion on actual content, rather than etiquette and
personalities, I find the distinction between "empty" and "doesn't exist"
quite interesting.
For some time now, I've been designing a data representation scheme around
what I'll call "smart datablocks". I found it very useful to have different
representations for a "null block", meaning the absence of a block where
one was expected, and an "empty block", meaning an ordinary data block,
but one whose payload is empty.
Bob Badour
> "mAsterdam" <mAst...@vrijdag.org> wrote in message
> news:44498707$0$31637$e4fe...@news.xs4all.nl...
>
>>Which? You mean between "I don't have a killfile" and "my killfile is
>>empty"? HAHAHAHAHA
>
> In the context of a discussion on actual content, rather than etiquette and
> personalities, I find the distinction between "empty" and "doesn't exist"
> quite interesting.
It is interesting. It is the difference between dee and dum, between 1
and 0, and between true and false.
In that line of thought, here's an interesting question that Date et al
have posed before to the n-VL folks:
If "exists but empty" is true and "doesn't exist" is false, what is null?
Frank Hamersley
Neither and both!
Its paradoxical in 3VL while obvious in 4VL - however the latter FWICT
adds no benefit to the truth table.
While null is not my favourite aspect of the RM, I remain to be
convinced that D is not a manifestly worse proposition. Perhaps you et
al can sway me?
Cheers, Frank.
Bob Badour
> Bob Badour wrote:
>
>> David Cressey wrote:
>>
>>> "mAsterdam" <mAst...@vrijdag.org> wrote in message
>>> news:44498707$0$31637$e4fe...@news.xs4all.nl...
>>>
>>>> Which? You mean between "I don't have a killfile" and "my killfile is
>>>> empty"? HAHAHAHAHA
>>>
>>>
>>> In the context of a discussion on actual content, rather than
>>> etiquette and
>>> personalities, I find the distinction between "empty" and "doesn't
>>> exist"
>>> quite interesting.
>>
>> It is interesting. It is the difference between dee and dum, between 1
>> and 0, and between true and false.
>>
>> In that line of thought, here's an interesting question that Date et
>> al have posed before to the n-VL folks:
>>
>> If "exists but empty" is true and "doesn't exist" is false, what is null?
>
> Neither and both!
I find that sort of handwaving to be a complete non-answer. A much more
intellectually honest reply would be: "I don't know." or "Null has no
similar analog in set theory." True and 1 both have the exact same
analog in set theory. False and 0 both have the exact same analog in set
theory. This has a certain elegance and symmetry.
In canonical form:
{} = 0 = false
{{}} = 1 = true
What is the similar analog for null?
Neo
>>
>> Neo: The worth-while-ness of such a "truth" is dubious if it only works "sometimes". It seems you are making a preassumption which may need verification. What is the preassumption?
>>
>> Neo: Actually what I meant by my prior polite comments and questions is: If you have come to feel that way then you are a *!@*! than Bob Badour.
>
> mAsterdam: Your and Bob's posts are very much alike. Boring. At first you treated most readers of cdt as morons by repeating the same blind spots over and over again, Bob simply picked out a few people who are relatively ignorant in his expertise area, called them names and actively blocks their communication at cdt. Boring and sickening. Suddenly you turn out to be able to actually read replies, and Bob turns out to be able to actually contribute. Great. I'm not an expert in what you and Bob are aiming for. Yet I think I have to say some valuable on topic things to both of you. I won't until I notice improvement in you showing respect.
Having received many names throughout serveral years, I can certainly
respect someone who finds name calling to be sickening. I will try to
remember that I am treating others like morons by repeating the same
blind spots over and over again. I will try to be less boring.
PS. Are you aware that my emulation of Bob and swearing in this thread
was to verify Jay Dee's hypothesis that being polite is sometimes a
greater barrier to communication than being rude?
dawn
<snip>
> While null is not my favourite aspect of the RM, I remain to be
> convinced that D is not a manifestly worse proposition. Perhaps you et
> al can sway me?
I much prefer the approach taken in D (IIRC) as I think there are real
cost savings with the simplicity of expressions being either true or
false. My experience (anecdotal) has been that both developers and
end-users make fewer mistakes and take less time figuring out what the
result of a query will be or what it means when using 2VL.
The link below is primarily descriptive rather than argumentative, it
is not about D but an existing language, and it describes what you
already grasp, but in spite of those caveats, you might enjoy reading:
http://www.tincat-group.com/mewsings/2006/03/better-to-have-no-values.html
Cheers! --dawn
Frank Hamersley
> Frank Hamersley wrote:
>
>> Bob Badour wrote:
[..]
>>> In that line of thought, here's an interesting question that Date et
>>> al have posed before to the n-VL folks:
>>>
>>> If "exists but empty" is true and "doesn't exist" is false, what is
>>> null?
>>
>> Neither and both!
>
> I find that sort of handwaving to be a complete non-answer.
I suspect you are wearing the darkly tinted glasses of preconception.
Whilst I was trying to show a little wit, the current 3VL state of
affairs still seems to me to fit that description.
> A much more
> intellectually honest reply would be: "I don't know."
Not from this black duck (on this occasion)!
> or "Null has no similar analog in set theory."
I wasn't comparing/contrasting the RM with set theory. Perhaps for you
it is implicit?
> True and 1 both have the exact same
> analog in set theory. False and 0 both have the exact same analog in set
> theory.
Perhaps but insistence on a parallel form for the RM does not seem to
lead anywhere practical*...FWICT.
> This has a certain elegance and symmetry.
I agree that and readily subscribe to that in my own endeavours.
> In canonical form:
>
> {} = 0 = false
> {{}} = 1 = true
>
> What is the similar analog for null?
My prior knowledge of your/the notation is non existent but I can prolly
deduce its intent. So having a stab at it how about ...
{}{} = null
As an aside (and with no malice aforethought) I am curious why the 0 and
1 figure at all? Forced to conform I would probably go with ...
{}{} = -1 = null
* (for another post perhaps) I don't see any great leap forward in the
aspects of TTM that address the extinction of nulls.
Cheers, Frank.
mAsterdam
> mAsterdam wrote
> [...]
>>Which? You mean between "I don't have a killfile" and "my killfile is
>>empty"? HAHAHAHAHA
>
>
> In the context of a discussion on actual content, rather than etiquette and
> personalities, I find the distinction between "empty" and "doesn't exist"
> quite interesting.
Yep. In another context it would be.
In the actual context, Bob Badour apologizing for not understanding,
however, it quickly becomes a ridicoulous escape route.
To reprovide the snipped context:
[...]=
Bob Badour wrote:
> mAsterdam wrote:
>
>> Bob Badour wrote:
>>
>>> mAsterdam wrote:
>>>
>>>> Bob Badour wrote:
>>>>
>>>>> They have been added to my killfile for ages. I only see what they
>>>>> write when somebody else excerpts it.
>>>>
>>>> On my list (ordered, by definition) of self-aggrandizing idiots you
>>>> rise.
>>>
>>>
>>> Your loss then. I really suggest you switch to a useful newsreader.
>>> Personally, I use Netscape Mail & Newsgroups, but I am sure lots of
>>> other newsreaders have killfiles.
>>
>>
>> Ah! Let's rephrase. My killfile is empty.
>> You did not understand that?
>> Pity. Pity you.
>
>
> Sorry. "Not exists" and "exists but empty" seem like a logical
> difference to me.
> For some time now, I've been designing a data representation scheme around
> what I'll call "smart datablocks". I found it very useful to have different
> representations for a "null block", meaning the absence of a block where
> one was expected, and an "empty block", meaning an ordinary data block,
> but one whose payload is empty.
To talk about that, you really should change the subject line.
mAsterdam
> Having received many names throughout serveral years, I can certainly
> respect someone who finds name calling to be sickening. I will try to
> remember that I am treating others like morons by repeating the same
> blind spots over and over again. I will try to be less boring.
Thank you.
> PS. Are you aware that my emulation of Bob and swearing in this thread
> was to verify Jay Dee's hypothesis that being polite is sometimes a
> greater barrier to communication than being rude?
Yep.
Sometimes I am impolite.
I don't know all rituals of all groups I am in.
Sometimes I even don't care about all its rituals.
Deliberate impoliteness is very rare to me, I am not
skilled at it. It may be efective at times.
Systematic deliberate impoliteness crosses a border
I do not wish to cross. I've seen to much damage of it.
Bob Badour
> Bob Badour wrote:
>
>> Frank Hamersley wrote:
>>
>>> Bob Badour wrote:
>
> [..]
>
>>>> In that line of thought, here's an interesting question that Date et
>>>> al have posed before to the n-VL folks:
>>>>
>>>> If "exists but empty" is true and "doesn't exist" is false, what is
>>>> null?
>>>
>>> Neither and both!
>>
>> I find that sort of handwaving to be a complete non-answer.
>
> I suspect you are wearing the darkly tinted glasses of preconception.
> Whilst I was trying to show a little wit, the current 3VL state of
> affairs still seems to me to fit that description.
>
>> A much more intellectually honest reply would be: "I don't know."
>
> Not from this black duck (on this occasion)!
>
>> or "Null has no similar analog in set theory."
>
> I wasn't comparing/contrasting the RM with set theory. Perhaps for you
> it is implicit?
No, it is quite explicit. Relations are sets. Relational algebra is the
equivalent of set theory, and relational calculus is the equivalent of
predicate calculus.
Thus, the equivalence of dee and true and of dum and false are very
important. And the question of what relation value equates to null is a
very good question.
>> True and 1 both have the exact same analog in set theory. False and 0
>> both have the exact same analog in set theory.
>
> Perhaps but insistence on a parallel form for the RM does not seem to
> lead anywhere practical*...FWICT.
Are you suggesting that query transformations lack practical benefits?
>> This has a certain elegance and symmetry.
>
> I agree that and readily subscribe to that in my own endeavours.
>
>> In canonical form:
>>
>> {} = 0 = false
>> {{}} = 1 = true
>>
>> What is the similar analog for null?
>
> My prior knowledge of your/the notation is non existent but I can prolly
> deduce its intent. So having a stab at it how about ...
>
> {}{} = null
{} is the empty set and is the set with cardinality 0.
{{}} is the set containing an empty set and is the canonical form of all
sets with cardinality 1.
{{},{{}}} is the canonical set with cardinality 2.
http://www.math.psu.edu/simpson/papers/philmath/node17.html
One can continue in this vein until Goedel stomps on one.
http://en.wikipedia.org/wiki/G%C3%B6del%27s_incompleteness_theorems
With respect to {}{} either it is completely meaningless, or perhaps you
intend the juxtaposition of two sets to mean conjunction or disjunction,
in which case:
{}{} = {} = false
If null and false are the same, we can do away with null.
> As an aside (and with no malice aforethought) I am curious why the 0 and
> 1 figure at all? Forced to conform I would probably go with ...
>
> {}{} = -1 = null
0 and 1 figure by tying into the formalism for whole numbers as shown above.
http://en.wikipedia.org/wiki/Foundations_of_mathematics
I direct your attention to:
http://en.wikipedia.org/wiki/Formalism#Mathematics
"Complete formalisation is in fact in the domain rather of computer
science."
And finally, the relational model is itself a formal system:
http://en.wikipedia.org/wiki/Formal_system
See also:
http://en.wikipedia.org/wiki/Category:Mathematical_logic
> * (for another post perhaps) I don't see any great leap forward in the
> aspects of TTM that address the extinction of nulls.
If nulls cause great damange without serving any particularly useful
purpose, why should one address their extinction?
Neo
> > was to verify Jay Dee's hypothesis that being polite is sometimes a
> > greater barrier to communication than being rude?
>
:) Great, then I don't mind being hailed for being boring and
repetitious.
Frank Hamersley
> Frank Hamersley wrote:
>> Bob Badour wrote:
>>> Frank Hamersley wrote:
>>>> Bob Badour wrote:
>>
>> [..]
>>
>>>>> In that line of thought, here's an interesting question that Date
>>>>> et al have posed before to the n-VL folks:
>>>>>
>>>>> If "exists but empty" is true and "doesn't exist" is false, what is
>>>>> null?
>>>>
>>>> Neither and both!
>>>
>>> I find that sort of handwaving to be a complete non-answer.
>>
>> I suspect you are wearing the darkly tinted glasses of preconception.
>> Whilst I was trying to show a little wit, the current 3VL state of
>> affairs still seems to me to fit that description.
>>
>>> A much more intellectually honest reply would be: "I don't know."
>>
>> Not from this black duck (on this occasion)!
>>
>>> or "Null has no similar analog in set theory."
>>
>> I wasn't comparing/contrasting the RM with set theory. Perhaps for
>> you it is implicit?
>
> No, it is quite explicit.
I am quite interested in exploring this area so please bear with me as
my analysis is heavily tainted with practical experience and less
(recently) so with formal theoretical studies. My response may be
somewhat affected by the serial reading and responding to your post and
I never feel comfortable with long posts when it finally is time to
click send!
> Relations are sets.
ALL relations are sets? My gut feeling is that this is not true. I
recognise that I hold to this because I view it from the damaged goods
position (aka SQL) or the RM as propounded by Codd, rather than from a
sounder theoretical starting point. I understand this puts us at odds
from inception. From there I expect anything brought to this issue by
theory will be elegant, symmetrical _and_ compelling.
[2nd editing]
Having read the texts, below I felt inclined to retract the above para,
but then decided to leave it so you could form your own view on how
wacky my thinking might be. That said perhaps the fact that nulls do
exist in the RM today taken with your confirmed view that they shouldn't
(from a theoretical basis) is implied confirmation of my rather unlikely
original thought...he says stepping back two full paces - did I write that?
> Relational algebra is the
> equivalent of set theory, and relational calculus is the equivalent of
> predicate calculus.
I have no beef here.
> Thus, the equivalence of dee and true and of dum and false are very
> important. And the question of what relation value equates to null is a
> very good question.
Lets put that aside until the first question has been addressed.
>>> True and 1 both have the exact same analog in set theory. False and 0
>>> both have the exact same analog in set theory.
>>
>> Perhaps but insistence on a parallel form for the RM does not seem to
>> lead anywhere practical*...FWICT.
>
> Are you suggesting that query transformations lack practical benefits?
No sure where you are going here, can you be specific or illustrate?
>>> This has a certain elegance and symmetry.
>>
>> I agree that and readily subscribe to that in my own endeavours.
>>
>>> In canonical form:
>>>
>>> {} = 0 = false
>>> {{}} = 1 = true
>>>
>>> What is the similar analog for null?
>>
>> My prior knowledge of your/the notation is non existent but I can
>> prolly deduce its intent. So having a stab at it how about ...
>>
>> {}{} = null
>
> {} is the empty set and is the set with cardinality 0.
> {{}} is the set containing an empty set and is the canonical form of all
> sets with cardinality 1.
> {{},{{}}} is the canonical set with cardinality 2.
> http://www.math.psu.edu/simpson/papers/philmath/node17.html
Interesting read. However it seems the jury is not even cloistered yet!
I quote "The implications of this idea are not yet fully understood and
are a topic of current research". Of course, this is from a web page ;-)
> One can continue in this vein until Goedel stomps on one.
> http://en.wikipedia.org/wiki/G%C3%B6del%27s_incompleteness_theorems
OK - it reminds me of a statement made in undergrad science that "you
don't prove a hypothesis, you can only disprove it". Of course Godel is
more complete than that.
> With respect to {}{} either it is completely meaningless, or perhaps you
> intend the juxtaposition of two sets to mean conjunction or disjunction,
> in which case:
> {}{} = {} = false
It was just a wild punt - the intent was to suggest that two empty sets
were distinct and that their intersection was indefinable.
> If null and false are the same, we can do away with null.
They aren't but I guess it may be feasible to do away with null in the
truth table ie. null implies false. I expect you would still need its
physical presence in the manifestation of tables/relations.
>> As an aside (and with no malice aforethought) I am curious why the 0
>> and 1 figure at all? Forced to conform I would probably go with ...
>>
>> {}{} = -1 = null
>
> 0 and 1 figure by tying into the formalism for whole numbers as shown
> above.
> http://en.wikipedia.org/wiki/Foundations_of_mathematics
>
> I direct your attention to:
> http://en.wikipedia.org/wiki/Formalism#Mathematics
>
> "Complete formalisation is in fact in the domain rather of computer
> science."
>
> And finally, the relational model is itself a formal system:
>
> http://en.wikipedia.org/wiki/Formal_system
>
> See also:
> http://en.wikipedia.org/wiki/Category:Mathematical_logic
Thanks for the pointers - admittedly I have only limited time and have
had to skim through the material, however it was apparent that there
remains substantial areas where consensus has not been achieved (yet).
>> * (for another post perhaps) I don't see any great leap forward in the
>> aspects of TTM that address the extinction of nulls.
>
> If nulls cause great damange without serving any particularly useful
> purpose, why should one address their extinction?
No quite sure what your thrust is here, perhaps you would like to edit
it given the damage (sic) it has suffered? In advance of that, I can
state that I don't hold that nulls cause _great_ damage (although
neither does Semtex in capable hands for a proper purpose) and I
certainly believe (at this point) that they do serve a purpose. As to
Date and Darwens attempt to remove nulls as shown in the Tutorial-D
slides it didn't seem to meet the elegance or compelling stature I
mentioned before.
Cheers, Frank.
Bob Badour
Yes, ALL relations are sets of tuples. SQL tables are not relation
variables and do not contain relations.
My gut feeling is that this is not true. I
> recognise that I hold to this because I view it from the damaged goods
> position (aka SQL) or the RM as propounded by Codd, rather than from a
> sounder theoretical starting point.
RM/V2 seems flawed to me. I am not sure whether I have ever found a
complete copy of RM/T. Did Codd ever advocate null prior to RM/T? Did he
ever drop the requirement for logical identity?
I understand this puts us at odds
> from inception. From there I expect anything brought to this issue by
> theory will be elegant, symmetrical _and_ compelling.
Relations are elegant, symmetrical and compelling. Bags and null are
none of those.
> [2nd editing]
> Having read the texts, below I felt inclined to retract the above para,
> but then decided to leave it so you could form your own view on how
> wacky my thinking might be. That said perhaps the fact that nulls do
> exist in the RM today taken with your confirmed view that they shouldn't
> (from a theoretical basis) is implied confirmation of my rather unlikely
> original thought...he says stepping back two full paces - did I write that?
Whether nulls exist in the RM today is a topic of some controversy.
>> Relational algebra is the equivalent of set theory, and relational
>> calculus is the equivalent of predicate calculus.
>
> I have no beef here.
With null or without logical identity, they lack the equivalences mentioned.
>> Thus, the equivalence of dee and true and of dum and false are very
>> important. And the question of what relation value equates to null is
>> a very good question.
>
> Lets put that aside until the first question has been addressed.
Shall we get back to this now?
>>>> True and 1 both have the exact same analog in set theory. False and
>>>> 0 both have the exact same analog in set theory.
>>>
>>> Perhaps but insistence on a parallel form for the RM does not seem to
>>> lead anywhere practical*...FWICT.
>>
>> Are you suggesting that query transformations lack practical benefits?
>
> No sure where you are going here, can you be specific or illustrate?
The equivalence between relation values and boolean values facilitates
certain query transformations such as between a union and an 'or'
predicate and vice versa.
>>>> This has a certain elegance and symmetry.
>>>
>>> I agree that and readily subscribe to that in my own endeavours.
>>>
>>>> In canonical form:
>>>>
>>>> {} = 0 = false
>>>> {{}} = 1 = true
>>>>
>>>> What is the similar analog for null?
>>>
>>> My prior knowledge of your/the notation is non existent but I can
>>> prolly deduce its intent. So having a stab at it how about ...
>>>
>>> {}{} = null
>>
>> {} is the empty set and is the set with cardinality 0.
>> {{}} is the set containing an empty set and is the canonical form of
>> all sets with cardinality 1.
>> {{},{{}}} is the canonical set with cardinality 2.
>> http://www.math.psu.edu/simpson/papers/philmath/node17.html
>
> Interesting read. However it seems the jury is not even cloistered yet!
> I quote "The implications of this idea are not yet fully understood and
> are a topic of current research". Of course, this is from a web page ;-)
Goedel established limitations to formalism as the foundation of
mathematics, and I am not sure that philosophy is meant to have an endpoint.
>> One can continue in this vein until Goedel stomps on one.
>> http://en.wikipedia.org/wiki/G%C3%B6del%27s_incompleteness_theorems
>
> OK - it reminds me of a statement made in undergrad science that "you
> don't prove a hypothesis, you can only disprove it". Of course Godel is
> more complete than that.
LOL
>> With respect to {}{} either it is completely meaningless, or perhaps
>> you intend the juxtaposition of two sets to mean conjunction or
>> disjunction, in which case:
>> {}{} = {} = false
>
> It was just a wild punt - the intent was to suggest that two empty sets
> were distinct and that their intersection was indefinable.
One wonders in what way they are distinct. Is 1 distinct from 1? Is 0
distinct from 0? Obviously, as values, they are indistinct. One must
then posit that they differ in location. However, a single attribute
within a single tuple within a single relation variable has a unique
logical location. How then can null equate to two locations? What then
does it mean when the null appears in a derived value which has no
location at all?
>> If null and false are the same, we can do away with null.
>
> They aren't but I guess it may be feasible to do away with null in the
> truth table ie. null implies false. I expect you would still need its
> physical presence in the manifestation of tables/relations.
If null is not the same as false, then it is not the same as {}. Does it
then have an equivalent set representation?
>>> As an aside (and with no malice aforethought) I am curious why the 0
>>> and 1 figure at all? Forced to conform I would probably go with ...
>>>
>>> {}{} = -1 = null
>>
>> 0 and 1 figure by tying into the formalism for whole numbers as shown
>> above.
>> http://en.wikipedia.org/wiki/Foundations_of_mathematics
>>
>> I direct your attention to:
>> http://en.wikipedia.org/wiki/Formalism#Mathematics
>>
>> "Complete formalisation is in fact in the domain rather of computer
>> science."
>>
>> And finally, the relational model is itself a formal system:
>>
>> http://en.wikipedia.org/wiki/Formal_system
>>
>> See also:
>> http://en.wikipedia.org/wiki/Category:Mathematical_logic
>
>
> Thanks for the pointers - admittedly I have only limited time and have
> had to skim through the material, however it was apparent that there
> remains substantial areas where consensus has not been achieved (yet).
I suspect your statement is true of all of mathematics and in fact of
all fields of study.
>>> * (for another post perhaps) I don't see any great leap forward in
>>> the aspects of TTM that address the extinction of nulls.
>>
>> If nulls cause great damange without serving any particularly useful
>> purpose, why should one address their extinction?
>
> No quite sure what your thrust is here, perhaps you would like to edit
> it given the damage (sic) it has suffered? In advance of that, I can
> state that I don't hold that nulls cause _great_ damage (although
> neither does Semtex in capable hands for a proper purpose) and I
> certainly believe (at this point) that they do serve a purpose.
Are you familiar with Date's various _Writings..._ books? He and Darwen
and others have demonstrated that null causes great damage.
Nulls attempt to address missing information but do so with no basis in
theory. I suggest that the null elixir only offers the illusion of power:
http://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD898.html
As to
> Date and Darwens attempt to remove nulls as shown in the Tutorial-D
> slides it didn't seem to meet the elegance or compelling stature I
> mentioned before.
Missing information is messy, and we lack any theory to address it.
Pretending otherwise may put the mess out of sight and out of mind, but
that just makes the mess worse and the problems more surprising when
re-discovered.
Frank Hamersley
OK - I presume the dichotomy is practice (SQL) vs theory (RM) in that
with the former tables can exist with repeated rows but in the latter it
presumes in a relation all tuples are distinct?
>> My gut feeling is that this is not true. I
>> recognise that I hold to this because I view it from the damaged goods
>> position (aka SQL) or the RM as propounded by Codd, rather than from a
>> sounder theoretical starting point.
>
> RM/V2 seems flawed to me. I am not sure whether I have ever found a
> complete copy of RM/T. Did Codd ever advocate null prior to RM/T? Did he
> ever drop the requirement for logical identity?
I'm not well read enough to be able to hazard answers to these
questions. I will does some more reading on these topics after I get
off Highway #1.
>> I understand this puts us at odds
>> from inception. From there I expect anything brought to this issue by
>> theory will be elegant, symmetrical _and_ compelling.
>
> Relations are elegant, symmetrical and compelling. Bags and null are
> none of those.
Relations it seems are E,S+C until missing information is added to the
mix. Bags and nulls are quite apparently not but from where I am now
the null at least seems the lesser of evils viz my post in the
"beautiful mind" thread.
>> [2nd editing]
>> Having read the texts, below I felt inclined to retract the above
>> para, but then decided to leave it so you could form your own view on
>> how wacky my thinking might be. That said perhaps the fact that nulls
>> do exist in the RM today taken with your confirmed view that they
>> shouldn't (from a theoretical basis) is implied confirmation of my
>> rather unlikely original thought...he says stepping back two full
>> paces - did I write that?
>
> Whether nulls exist in the RM today is a topic of some controversy.
Sure is - in biological terms noting that the bastard child SQL inherits
only half its genome from the known parent (RM) then the question is -
is it a meiotic mutation or a pre-existing recessive allele now
homozygous and perhaps deleterious?
>>> Relational algebra is the equivalent of set theory, and relational
>>> calculus is the equivalent of predicate calculus.
>>
>> I have no beef here.
>
> With null or without logical identity, they lack the equivalences
> mentioned.
By logical identity I take it you mean the distinctness of each tuple?
>>> Thus, the equivalence of dee and true and of dum and false are very
>>> important. And the question of what relation value equates to null is
>>> a very good question.
>>
>> Lets put that aside until the first question has been addressed.
>
> Shall we get back to this now?
Yep - although there probably no debate to be had once the various and
varying starting points are determined.
>>>>> True and 1 both have the exact same analog in set theory. False and
>>>>> 0 both have the exact same analog in set theory.
>>>>
>>>> Perhaps but insistence on a parallel form for the RM does not seem
>>>> to lead anywhere practical*...FWICT.
>>>
>>> Are you suggesting that query transformations lack practical benefits?
>>
>> No sure where you are going here, can you be specific or illustrate?
>
> The equivalence between relation values and boolean values facilitates
> certain query transformations such as between a union and an 'or'
> predicate and vice versa.
OK. Obviously useful for the theorist to explore stuff (apols to Alexi).
>>>>> This has a certain elegance and symmetry.
>>>>
>>>> I agree that and readily subscribe to that in my own endeavours.
>>>>
>>>>> In canonical form:
>>>>>
>>>>> {} = 0 = false
>>>>> {{}} = 1 = true
>>>>>
>>>>> What is the similar analog for null?
>>>>
>>>> My prior knowledge of your/the notation is non existent but I can
>>>> prolly deduce its intent. So having a stab at it how about ...
>>>>
>>>> {}{} = null
>>>
>>> {} is the empty set and is the set with cardinality 0.
>>> {{}} is the set containing an empty set and is the canonical form of
>>> all sets with cardinality 1.
>>> {{},{{}}} is the canonical set with cardinality 2.
>>> http://www.math.psu.edu/simpson/papers/philmath/node17.html
>>
>> Interesting read. However it seems the jury is not even cloistered
>> yet! I quote "The implications of this idea are not yet fully
>> understood and are a topic of current research". Of course, this is
>> from a web page ;-)
>
> Goedel established limitations to formalism as the foundation of
> mathematics, and I am not sure that philosophy is meant to have an
> endpoint.
Which I find (philosophy) much more interesting these days, although
much of it beyond me as a casual investigator.
>>> One can continue in this vein until Goedel stomps on one.
>>> http://en.wikipedia.org/wiki/G%C3%B6del%27s_incompleteness_theorems
>>
>> OK - it reminds me of a statement made in undergrad science that "you
>> don't prove a hypothesis, you can only disprove it". Of course Godel
>> is more complete than that.
>
> LOL
One the few occasions I can say I wish I had said that - and did!
>>> With respect to {}{} either it is completely meaningless, or perhaps
>>> you intend the juxtaposition of two sets to mean conjunction or
>>> disjunction, in which case:
>>> {}{} = {} = false
>>
>> It was just a wild punt - the intent was to suggest that two empty
>> sets were distinct and that their intersection was indefinable.
>
> One wonders in what way they are distinct. Is 1 distinct from 1? Is 0
> distinct from 0? Obviously, as values, they are indistinct. One must
> then posit that they differ in location.
So {1} and {1} are not distinct when conceptually imagined in an OO
instance frame of mind? Thus it would take something like {1,2} and
{1,3} at which point the sets are distinct? In this case are the 1's
distinct?
> However, a single attribute
> within a single tuple within a single relation variable has a unique
> logical location.
True.
> How then can null equate to two locations?
I'm guessing a bit here about your question - I take it to mean {1,null}
and {1,null} should not be seen as distinct but nVL insists they are?
> What then
> does it mean when the null appears in a derived value which has no
> location at all?
But the RM proscribes every value (derived or not) has a location does
it not - that is putting aside the stuff about nameless or duplicated
attributes etc?
>>> If null and false are the same, we can do away with null.
>>
>> They aren't but I guess it may be feasible to do away with null in the
>> truth table ie. null implies false. I expect you would still need its
>> physical presence in the manifestation of tables/relations.
>
> If null is not the same as false, then it is not the same as {}. Does it
> then have an equivalent set representation?
No, I don't think it does. As you say it is not {} and {null} does not
equal {null} - this is as I said before a paradoxical state of affairs
and clearly does not marry well with the formal approach to analysis.
[..]
>> Thanks for the pointers - admittedly I have only limited time and have
>> had to skim through the material, however it was apparent that there
>> remains substantial areas where consensus has not been achieved (yet).
>
> I suspect your statement is true of all of mathematics and in fact of
> all fields of study.
Which is why we two are assembled here today - not enough of us for a
riot however!
>>>> * (for another post perhaps) I don't see any great leap forward in
>>>> the aspects of TTM that address the extinction of nulls.
>>>
>>> If nulls cause great damange without serving any particularly useful
>>> purpose, why should one address their extinction?
>>
>> No quite sure what your thrust is here, perhaps you would like to edit
>> it given the damage (sic) it has suffered? In advance of that, I can
>> state that I don't hold that nulls cause _great_ damage (although
>> neither does Semtex in capable hands for a proper purpose) and I
>> certainly believe (at this point) that they do serve a purpose.
>
> Are you familiar with Date's various _Writings..._ books? He and Darwen
> and others have demonstrated that null causes great damage.
I don't need them to postulate it as I've seen it first hand. My
opinion of Date mainly and Darwen to a much lesser extent (more by
association than real research) is that whilst they have taken a pot
shot at a low flying albatross, they haven't come up with anything even
close to better. Being too tight to pay them for their various
treatises means that I prolly have limited information to base that view
upon but what I have seen doesn't thrill me one bit. Hence my 155 mm
post on the BM thread.
Given the lesser evil option I expect to rely on skilled practitioners
to mitigate the risk of that damage arising. Sadly they don't grow on
trees!
> Nulls attempt to address missing information but do so with no basis in
> theory. I suggest that the null elixir only offers the illusion of power:
> http://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD898.html
I understand your view. For the record mine is that null is no elixir -
more like Cod Liver Oil and there ain't no illusions when swallowing
that stuff.
>> As to
>> Date and Darwens attempt to remove nulls as shown in the Tutorial-D
>> slides it didn't seem to meet the elegance or compelling stature I
>> mentioned before.
>
> Missing information is messy, and we lack any theory to address it.
> Pretending otherwise may put the mess out of sight and out of mind, but
> that just makes the mess worse and the problems more surprising when
> re-discovered.
That is how I would characterise "D". On the theory side I am in a
prolonged contemplation on the missing dimension in SQL (as compared to
the RM) which is the temporal capability. I have made what I consider
to be some progress but it is premature to discuss publicly lest I end
up wearing lots of egg, suffice to say the null thang has a parallel in
temporal matters. BTW I don't rate Date & Darwens offering on this
either, nor FWIW much of the Snodgrass et al stuff that preceded them.
Cheers, Frank.
Bob Badour
Since SQL and RM are both theory and practical, your sentence is nonsense.
>>> I understand this puts us at odds
>>> from inception. From there I expect anything brought to this issue
>>> by theory will be elegant, symmetrical _and_ compelling.
>>
>> Relations are elegant, symmetrical and compelling. Bags and null are
>> none of those.
>
> Relations it seems are E,S+C until missing information is added to the
> mix. Bags and nulls are quite apparently not but from where I am now
> the null at least seems the lesser of evils viz my post in the
> "beautiful mind" thread.
Missing information is messy and we have no theory at all for addressing
it. Adding it to the RM in no way reduces the elegance, symmetry or
compellingness of the RM. Either one can use the E,S&C to tackle the
difficult problem, or one can pretend the problem doesn't exist.
Null pretends the problem exists. It reduces the expressiveness of the
language and hides people's errors from them. Can you imagine a compiler
that refused to reject any program or issue any warning?
>>> [2nd editing]
>>> Having read the texts, below I felt inclined to retract the above
>>> para, but then decided to leave it so you could form your own view on
>>> how wacky my thinking might be. That said perhaps the fact that
>>> nulls do exist in the RM today taken with your confirmed view that
>>> they shouldn't (from a theoretical basis) is implied confirmation of
>>> my rather unlikely original thought...he says stepping back two full
>>> paces - did I write that?
>>
>> Whether nulls exist in the RM today is a topic of some controversy.
>
> Sure is - in biological terms noting that the bastard child SQL inherits
> only half its genome from the known parent (RM) then the question is -
> is it a meiotic mutation or a pre-existing recessive allele now
> homozygous and perhaps deleterious?
Nonsensical handwaving.
>>>> Relational algebra is the equivalent of set theory, and relational
>>>> calculus is the equivalent of predicate calculus.
>>>
>>> I have no beef here.
>>
>> With null or without logical identity, they lack the equivalences
>> mentioned.
>
> By logical identity I take it you mean the distinctness of each tuple?
The identity of every explicit value in every relation. Since tuples are
values, logical identity includes those.
>>>> Thus, the equivalence of dee and true and of dum and false are very
>>>> important. And the question of what relation value equates to null
>>>> is a very good question.
>>>
>>> Lets put that aside until the first question has been addressed.
>>
>> Shall we get back to this now?
>
> Yep - although there probably no debate to be had once the various and
> varying starting points are determined.
More nonsensical handwaving. You have succeeded in one thing with your
evasiveness: you have demonstrated your lack of intellectual honesty and
integrity.
>>>>>> True and 1 both have the exact same analog in set theory. False
>>>>>> and 0 both have the exact same analog in set theory.
>>>>>
>>>>> Perhaps but insistence on a parallel form for the RM does not seem
>>>>> to lead anywhere practical*...FWICT.
>>>>
>>>> Are you suggesting that query transformations lack practical benefits?
>>>
>>> No sure where you are going here, can you be specific or illustrate?
>>
>> The equivalence between relation values and boolean values facilitates
>> certain query transformations such as between a union and an 'or'
>> predicate and vice versa.
>
> OK. Obviously useful for the theorist to explore stuff (apols to Alexi).
Obviously useful for the practitioner to explore as well. If the
practitioner never considers where the pitfalls lie, he will only
discover them from the bottom of the pit.
>>>> With respect to {}{} either it is completely meaningless, or perhaps
>>>> you intend the juxtaposition of two sets to mean conjunction or
>>>> disjunction, in which case:
>>>> {}{} = {} = false
>>>
>>> It was just a wild punt - the intent was to suggest that two empty
>>> sets were distinct and that their intersection was indefinable.
>>
>> One wonders in what way they are distinct. Is 1 distinct from 1? Is 0
>> distinct from 0? Obviously, as values, they are indistinct. One must
>> then posit that they differ in location.
>
> So {1} and {1} are not distinct when conceptually imagined in an OO
> instance frame of mind?
An OO instance is a variable. Thus the values of the two variables are
indistinct even if the variables themselves are distinct and
distinguishable by physical location.
Thus it would take something like {1,2} and
> {1,3} at which point the sets are distinct? In this case are the 1's
> distinct?
No, they are not. The value 1 is the value 1. They are equal. You have
given no other way to distinguish the values. In fact, in set theory:
{1} = {1,1} = {1,1,1}
>> However, a single attribute within a single tuple within a single
>> relation variable has a unique logical location.
>
> True.
>
>> How then can null equate to two locations?
>
> I'm guessing a bit here about your question - I take it to mean {1,null}
> and {1,null} should not be seen as distinct but nVL insists they are?
No, I was shredding your earlier try at an answer when you replied with
"{}{}=null".
>> What then does it mean when the null appears in a derived value which
>> has no location at all?
>
> But the RM proscribes every value (derived or not) has a location does
> it not - that is putting aside the stuff about nameless or duplicated
> attributes etc?
In the RM, logical identity locates a value within a variable. One can
change part of a variable for instance and the value at one or more
physical location(s) will change. The fact that values outside of
variables have no location further shreds your attempt at a reply with
"{}{}=null".
>>>> If null and false are the same, we can do away with null.
>>>
>>> They aren't but I guess it may be feasible to do away with null in
>>> the truth table ie. null implies false. I expect you would still
>>> need its physical presence in the manifestation of tables/relations.
>>
>> If null is not the same as false, then it is not the same as {}. Does
>> it then have an equivalent set representation?
>
> No, I don't think it does. As you say it is not {} and {null} does not
> equal {null} - this is as I said before a paradoxical state of affairs
> and clearly does not marry well with the formal approach to analysis.
And since all of programming is about formalism, I suggest null has no
effective role to play in any aspect of programming.
I disagree. They have correctly identified that missing information as
of yet has no theory to address it. While I disagree with some of their
ad hoc attempts to address it differently than null, I suggest the RM --
without any special feature for missing information -- already handles
it as well as we can until someone establishes a valid theory addressing
missing information.
Null takes a bad situation and makes it worse. It does harm. Removing it
improves our lot.
> Given the lesser evil option I expect to rely on skilled practitioners
> to mitigate the risk of that damage arising. Sadly they don't grow on
> trees!
All the more reason to make simple queries easier to express correctly
so casual users do not have to waste the time of skilled practitioners
for very common, mundane queries.
>> Nulls attempt to address missing information but do so with no basis
>> in theory. I suggest that the null elixir only offers the illusion of
>> power:
>> http://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD898.html
>
> I understand your view. For the record mine is that null is no elixir -
> more like Cod Liver Oil and there ain't no illusions when swallowing
> that stuff.
If one takes the average age of a group of people where some of the ages
are unknown, then the average is unknown. With a relational dbms, I can
model the ages so that it returns the correct result, unknown.
When the user gets the result, the user has to ponder what that means
and how to proceed. If the user discovers that back in the old days
nobody bothered to record birthdates, the meaning is different than if
the ages are unknown because some of the people are fetuses as of yet
unborn.
Null is less expressible than the RM because it obviates the possibility
of returning the correct result. The result it returns is incorrect and
in the cases mentioned above is not even approximately correct, but the
user has no alert to the problem.
If that is not an illusion of power, I don't know what is. As a solution
for the problem of missing information, null is an elixir. Since your
earlier evasiveness has revealed your lack of intellectual honesty, I
will dismiss your denials as groundless.
>>> As to
>>> Date and Darwens attempt to remove nulls as shown in the Tutorial-D
>>> slides it didn't seem to meet the elegance or compelling stature I
>>> mentioned before.
>>
>> Missing information is messy, and we lack any theory to address it.
>> Pretending otherwise may put the mess out of sight and out of mind,
>> but that just makes the mess worse and the problems more surprising
>> when re-discovered.
>
> That is how I would characterise "D". On the theory side I am in a
> prolonged contemplation on the missing dimension in SQL (as compared to
> the RM) which is the temporal capability. I have made what I consider
> to be some progress but it is premature to discuss publicly lest I end
> up wearing lots of egg, suffice to say the null thang has a parallel in
> temporal matters. BTW I don't rate Date & Darwens offering on this
> either, nor FWIW much of the Snodgrass et al stuff that preceded them.
Yes, well, get back to us when you have something substantive to offer
that won't leave egg on your face.
Gene Wirchenko
>>>> ... you have the words but not the tune
>.
>>> :) Sorry but I find your response to be antiprocess-like
>>> and thus refuse to engage it any further. For details see
>>> http://members.aol.com/intwg/antiprocess.htm
>.
>> My lucky day.
>
>Actually what I meant by my prior polite comment was: Gene you are the
>BIGGEST FUCKING MORON, even bigger than Jay Dee and Bob Badour put
>together.
You make more sense when you are swearing at people than when you
try foisting your db nonsense on us.
You still are not right, but you are making more sense.
Attaining correctness can be a bugbear, but you may get there
yet.
Sincerely,
Gene Wirchenko
Frank Hamersley
> Frank Hamersley wrote:
>> Bob Badour wrote:
>>> Frank Hamersley wrote:
>>>> Bob Badour wrote:
>>>>> Frank Hamersley wrote:
>>>>>> Bob Badour wrote:
>>>>>>> Frank Hamersley wrote:
>>>>>>>> Bob Badour wrote:
[..] time for a haircut!
>> OK - I presume the dichotomy is practice (SQL) vs theory (RM) in that
>> with the former tables can exist with repeated rows but in the latter it
>> presumes in a relation all tuples are distinct?
>
> Since SQL and RM are both theory and practical, your sentence is nonsense.
Preempting some of your various replies below you seem to be getting
fatigued of this topic. Regardless, for me the RM is the theory and SQL
is the practice. Sure the latter "contains" some or all the former but
using this distinction adequately provides terms or reference for me as
"where we are" against "where we want to be". I don't think I can help
you much more than that.
[..]
> Missing information is messy and we have no theory at all for addressing
> it. Adding it to the RM in no way reduces the elegance, symmetry or
> compellingness of the RM.
Rubbish - IMO the whole is less for the adding the messy bit without
resolving it to meet the ES+C criteria. Sure the other parts are just
as ES+C as they were before when taken in isolation. This is akin to
the mess that existed in the prediction of planetary orbits prior to
Newtons apple.
> Either one can use the E,S&C to tackle the
> difficult problem, or one can pretend the problem doesn't exist.
This sounds overtly minimalist on your part. If I read it correctly on
the one hand you state there is no theory to support missing info and
then you propose to solve the issue solely with the theory at hand
whilst dismissing all other possibilities - to toss in a barb that seem
as ostrich like as it gets.
> Null pretends the problem exists.
There is no need for pretense is there?
> It reduces the expressiveness of the
> language and hides people's errors from them. Can you imagine a compiler
> that refused to reject any program or issue any warning?
Nup - unless the optimizer deduced the erroneous code was unreachable!
That of course would be pointlessness^2.
In the same vein can you imagine a compiler that checked for speeling
(sic) mistakes in manifest string constants?
[..]
>>> Whether nulls exist in the RM today is a topic of some controversy.
>>
>> Sure is - in biological terms noting that the bastard child SQL
>> inherits only half its genome from the known parent (RM) then the
>> question is - is it a meiotic mutation or a pre-existing recessive
>> allele now homozygous and perhaps deleterious?
>
> Nonsensical handwaving.
Is this code for I don't understand or simply can't be bothered? If so
I will happily limit my discourse to a dry form however I had picked you
as a well read energetic type.
[..]
>> By logical identity I take it you mean the distinctness of each tuple?
>
> The identity of every explicit value in every relation. Since tuples are
> values, logical identity includes those.
OK.
[..]
>> Yep - although there probably no debate to be had once the various
>> and varying starting points are determined.
>
> More nonsensical handwaving. You have succeeded in one thing with your
> evasiveness: you have demonstrated your lack of intellectual honesty and
> integrity.
More fatigue? Its pretty simple really - if I start with your
assumptions I agree your conclusions. If I vary them we end up apart.
Should I vary them? That is the point of interest for me at least - if
that is tiresome for you - ce la vie.
[..]
>> OK. Obviously useful for the theorist to explore stuff (apols to Alexi).
>
> Obviously useful for the practitioner to explore as well. If the
> practitioner never considers where the pitfalls lie, he will only
> discover them from the bottom of the pit.
Sure - and these pits are often filled with tar! What I was alluding to
is a practitioner accepting the theory can avoid exploring the pits by
sticking to the provided map. Of course it is a worthy goal for all
practitioners to understand as well as apply best practice.
[..]
>> So {1} and {1} are not distinct when conceptually imagined in an OO
>> instance frame of mind?
>
> An OO instance is a variable. Thus the values of the two variables are
> indistinct even if the variables themselves are distinct and
> distinguishable by physical location.
No drama here.
>> Thus it would take something like {1,2} and
>> {1,3} at which point the sets are distinct? In this case are the 1's
>> distinct?
>
> No, they are not. The value 1 is the value 1. They are equal. You have
> given no other way to distinguish the values. In fact, in set theory:
>
> {1} = {1,1} = {1,1,1}
OK.
>>> However, a single attribute within a single tuple within a single
>>> relation variable has a unique logical location.
>>
>> True.
>>
>>> How then can null equate to two locations?
>>
>> I'm guessing a bit here about your question - I take it to mean
>> {1,null} and {1,null} should not be seen as distinct but nVL insists
>> they are?
>
> No, I was shredding your earlier try at an answer when you replied with
> "{}{}=null".
>
>>> What then does it mean when the null appears in a derived value which
>>> has no location at all?
>>
>> But the RM proscribes every value (derived or not) has a location does
>> it not - that is putting aside the stuff about nameless or duplicated
>> attributes etc?
>
> In the RM, logical identity locates a value within a variable. One can
> change part of a variable for instance and the value at one or more
> physical location(s) will change. The fact that values outside of
> variables have no location further shreds your attempt at a reply with
> "{}{}=null".
Hmmm - I thought we had got past this windmill - we have now?
[..]
>> No, I don't think it does. As you say it is not {} and {null} does not
>> equal {null} - this is as I said before a paradoxical state of affairs
>> and clearly does not marry well with the formal approach to analysis.
>
> And since all of programming is about formalism, I suggest null has no
> effective role to play in any aspect of programming.
Very sloppy words! I would say intellectual honesty arises when you are
prepared to say something like "since all of programming *theory* is
about formalism, I suggest null has no effective role to play ..." Of
course I would be interested to see you ante up and describe a
fundamental and complete solution rather than simply taking your bat and
ball home.
[..]
>>> Are you familiar with Date's various _Writings..._ books? He and
>>> Darwen and others have demonstrated that null causes great damage.
>>
>> I don't need them to postulate it as I've seen it first hand. My
>> opinion of Date mainly and Darwen to a much lesser extent (more by
>> association than real research) is that whilst they have taken a pot
>> shot at a low flying albatross, they haven't come up with anything
>> even close to better.
>
> I disagree. They have correctly identified that missing information as
> of yet has no theory to address it.
That is a trivial conclusion! Where's the beef? You don't need to be a
luminary to get this far - do you?
> While I disagree with some of their
> ad hoc attempts to address it differently than null, I suggest the RM --
> without any special feature for missing information -- already handles
> it as well as we can until someone establishes a valid theory addressing
> missing information.
>
> Null takes a bad situation and makes it worse. It does harm. Removing it
> improves our lot.
I'm all eyes! I'm happy to consign null to oblivion if you give me a
_credible_ solution which means it must meet ES+C to accommodate my
limited analytical abilities.
>> Given the lesser evil option I expect to rely on skilled practitioners
>> to mitigate the risk of that damage arising. Sadly they don't grow on
>> trees!
>
> All the more reason to make simple queries easier to express correctly
> so casual users do not have to waste the time of skilled practitioners
> for very common, mundane queries.
I can relate to that - but I for one don't see your mundane queries as
in the problem domain. Viable practitioners can design RM compliant
systems using SQL if required. The real issue is solving the difficult
queries - something which D+D skate glibly over as I pointed out.
>>> Nulls attempt to address missing information but do so with no basis
>>> in theory. I suggest that the null elixir only offers the illusion of
>>> power:
>>> http://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD898.html
>>
>> I understand your view. For the record mine is that null is no elixir
>> - more like Cod Liver Oil and there ain't no illusions when swallowing
>> that stuff.
>
> If one takes the average age of a group of people where some of the ages
> are unknown, then the average is unknown. With a relational dbms, I can
> model the ages so that it returns the correct result, unknown.
I can cope with that - I would have no problem being forced to write
"select avg(age) from table where age is not null"
to get the crappy statistic that it is if the user demanded it. But I
thought you wanted to eradicate the nulls period?
> When the user gets the result, the user has to ponder what that means
> and how to proceed. If the user discovers that back in the old days
> nobody bothered to record birthdates, the meaning is different than if
> the ages are unknown because some of the people are fetuses as of yet
> unborn.
You are taking on too much methinks - if a mug user wants to buy
birthday presents for fetii why should the RM be saddled with saving him
from his own stupidity. Better IMO to focus on those who want to be saved.
> Null is less expressible than the RM because it obviates the possibility
> of returning the correct result. The result it returns is incorrect and
> in the cases mentioned above is not even approximately correct, but the
> user has no alert to the problem.
Unskilled users yes - as for me I am prepared to take my chances until
the GUT (Grand Unified Theory) arrives at which point I will happily
adopt it.
> If that is not an illusion of power, I don't know what is. As a solution
> for the problem of missing information, null is an elixir. Since your
> earlier evasiveness has revealed your lack of intellectual honesty, I
> will dismiss your denials as groundless.
Ah well we all have crosses to bear - suffice to say there are no
illusions on my part.
[..]
>> That is how I would characterise "D". On the theory side I am in a
>> prolonged contemplation on the missing dimension in SQL (as compared
>> to the RM) which is the temporal capability. I have made what I
>> consider to be some progress but it is premature to discuss publicly
>> lest I end up wearing lots of egg, suffice to say the null thang has a
>> parallel in temporal matters. BTW I don't rate Date & Darwens
>> offering on this either, nor FWIW much of the Snodgrass et al stuff
>> that preceded them.
>
> Yes, well, get back to us when you have something substantive to offer
> that won't leave egg on your face.
No problem. In the meantime I am happy for you to advance something
more than a simple change to the behaviour of avg().
Cheers, Frank.
Marshall Spight
>
> I can cope with that - I would have no problem being forced to write
>
> "select avg(age) from table where age is not null"
>
> to get the crappy statistic that it is if the user demanded it.
I dunno. If you have a whole lot of people and most of them
have their ages filled in and a few don't, are you ever going
to want to ask, "what is the average age", since the answer
will always be "unknown." Doesn't seem much use to me.
If you want to know if any of them are unknown, you could
ask that specifically. But if you want to know the average
age, then you want to know the average of the data you have;
you're not asking about the data you don't have because
you don't have it. The only useful query in there is "give
me the average age for the data I have"; why should we
make the way you ask for that longer winded than other,
never-useful queries?
And how "crappy" is that statistic anyway? Probably not
at all crappy. It's probably exactly what you want.
The idea of null as something that taints everything it
touches doesn't seem useful or practical to me.
Marshall
Frank Hamersley
I fully understand the sentiment however in cases like this I prefer
arrangements that retain flexibility for the (awake) programmer and
provide a form of simple clarity. i.e. if there is one null the avg()
is null. It would not take long for the industry to adopt this although
with all existing code out there a change might take on Y2K proportions!
This simplistic approach means any stray nulls creeping into a dataset
where none are expected will not go undetected if inadequately
constrained queries are framed. Of course this a very late stage to be
worrying about data integrity but better late than never.
Of course this is a simple case which is why I am interested to see if
Bob comes up with insights into something more difficult.
Cheers, Frank.
JOG
PMFJI, I thought it might be useful to point out that spreadsheets have
had to address this problem since their inception. As far as I know
they, by default, ignore empty cells when averaging ranges, as opposed
to dropping out with an error. As such they view the empty cell as as
not existing in the range at all. If all cells are empty then no range
exists and an error results.
Bob Badour
> Bob Badour wrote:
>
>> Frank Hamersley wrote:
>>
>>> Bob Badour wrote:
>>>
>>>> Frank Hamersley wrote:
>>>>
>>>>> Bob Badour wrote:
>>>>>
>>>>>> Frank Hamersley wrote:
>>>>>>
>>>>>>> Bob Badour wrote:
>>>>>>>
>>>>>>>> Frank Hamersley wrote:
>>>>>>>>
>>>>>>>>> Bob Badour wrote:
>
> [..] time for a haircut!
>
>>> OK - I presume the dichotomy is practice (SQL) vs theory (RM) in that
>>> with the former tables can exist with repeated rows but in the latter it
>>> presumes in a relation all tuples are distinct?
>>
>> Since SQL and RM are both theory and practical, your sentence is
>> nonsense.
>
> Preempting some of your various replies below you seem to be getting
> fatigued of this topic. Regardless, for me the RM is the theory and SQL
> is the practice. Sure the latter "contains" some or all the former but
> using this distinction adequately provides terms or reference for me as
> "where we are" against "where we want to be". I don't think I can help
> you much more than that.
It's rather presumptuous of you to think I need any help. SQL is rather
flawed theory based on multisets or bags and 3-vl, sort of. Ignoring the
principle of cautious design, those who first created SQL made arbitrary
and unecessary decisions that altered the theory dramatically from where
it started in the RM.
To say that SQL is not theory is just plain wrong. And to suggest that
the impractical consequences of those arbitrary decisions makes SQL
somehow practical is perverse.
> [..]
>
>> Missing information is messy and we have no theory at all for
>> addressing it. Adding it to the RM in no way reduces the elegance,
>> symmetry or compellingness of the RM.
>
> Rubbish - IMO the whole is less for the adding the messy bit without
> resolving it to meet the ES+C criteria. Sure the other parts are just
> as ES+C as they were before when taken in isolation. This is akin to
> the mess that existed in the prediction of planetary orbits prior to
> Newtons apple.
More nonsensical handwaving. Since you don't have anything substantive
to offer, you will be joining the self-aggrandizing ignorants at the
bottom of the killfile.
>> Either one can use the E,S&C to tackle the difficult problem, or one
>> can pretend the problem doesn't exist.
>
> This sounds overtly minimalist on your part. If I read it correctly on
> the one hand you state there is no theory to support missing info and
> then you propose to solve the issue solely with the theory at hand
> whilst dismissing all other possibilities - to toss in a barb that seem
> as ostrich like as it gets.
Pretending that null solves the problem of missing information is as
ostrich-like as it gets. "Problem? What problem? We have null."
Except that null only exacerbates the problem while creating myriad new
problems. You have said nothing that addresses this fact--a fact well
documented over the past 20 years.
>> It reduces the expressiveness of the language and hides people's
>> errors from them. Can you imagine a compiler that refused to reject
>> any program or issue any warning?
>
> Nup - unless the optimizer deduced the erroneous code was unreachable!
> That of course would be pointlessness^2.
Yes, a language that allows one only to describe unreachable code would
be rather pointless. But not quite as pointless as your response.
>>>> Whether nulls exist in the RM today is a topic of some controversy.
>>>
>>> Sure is - in biological terms noting that the bastard child SQL
>>> inherits only half its genome from the known parent (RM) then the
>>> question is - is it a meiotic mutation or a pre-existing recessive
>>> allele now homozygous and perhaps deleterious?
>>
>> Nonsensical handwaving.
>
> Is this code for I don't understand or simply can't be bothered?
It says exactly what it says. Your 'contributions' are almost entirely
void of substantive content. SQL is not a product of sexual
reproduction. If you are confused on that point, you have much more
serious problems than I am starting to believe.
>>> Yep - although there probably no debate to be had once the various
>>> and varying starting points are determined.
>>
>> More nonsensical handwaving. You have succeeded in one thing with your
>> evasiveness: you have demonstrated your lack of intellectual honesty
>> and integrity.
>
> More fatigue?
No, just a realistic evaluation of your worth as a participant here.
>>> OK. Obviously useful for the theorist to explore stuff (apols to Alexi).
>>
>> Obviously useful for the practitioner to explore as well. If the
>> practitioner never considers where the pitfalls lie, he will only
>> discover them from the bottom of the pit.
>
> Sure - and these pits are often filled with tar! What I was alluding to
> is a practitioner accepting the theory can avoid exploring the pits by
> sticking to the provided map. Of course it is a worthy goal for all
> practitioners to understand as well as apply best practice.
More nonsensical handwaving. We were not discussing a single theory but
comparing formalisms. A practitioner, who is unable to choose notations
and evaluate formalisms, or who is unwilling to think, has no real
business in computing.
>>> So {1} and {1} are not distinct when conceptually imagined in an OO
>>> instance frame of mind?
>>
>> An OO instance is a variable. Thus the values of the two variables are
>> indistinct even if the variables themselves are distinct and
>> distinguishable by physical location.
>
> No drama here.
But what is the physical location of a variable in a distributed database.
>>> Thus it would take something like {1,2} and
>>> {1,3} at which point the sets are distinct? In this case are the 1's
>>> distinct?
>>
>> No, they are not. The value 1 is the value 1. They are equal. You have
>> given no other way to distinguish the values. In fact, in set theory:
>>
>> {1} = {1,1} = {1,1,1}
>
> OK.
>
>>> No, I don't think it does. As you say it is not {} and {null} does
>>> not equal {null} - this is as I said before a paradoxical state of
>>> affairs and clearly does not marry well with the formal approach to
>>> analysis.
>>
>> And since all of programming is about formalism, I suggest null has no
>> effective role to play in any aspect of programming.
>
> Very sloppy words! I would say intellectual honesty arises when you are
> prepared to say something like "since all of programming *theory* is
> about formalism, I suggest null has no effective role to play ..."
I stand by my words. Programming is applied mathematics even if most of
the so-called programmers in the world are too stupid and too ignorant
to even conceive of such a thing.
A program itself is a proof of some theory. Sadly, most programs written
prove the wrong theory.
> Of
> course I would be interested to see you ante up and describe a
> fundamental and complete solution rather than simply taking your bat and
> ball home.
The relational model without any additional adornment suffices as well
as any other formalism for handling missing information. The relational
model is already well-described. If you want to propose a solution for
missing information, the onus lies on you to prove the worth of the
proposal relative to the original model.
Null reduces expressibility, limits opportunities for query rewriting,
yields incorrect results, is poorly understood by many experienced
practitioners not to mention casual users, violates the information
principle, and in the case of SQL is inconsistent. I reject it by any
number of objective criteria.
Illusions of power are just that: illusions. Handling missing
information is not easy and requires careful thought in every instance.
Sure it saves time to ignore the problem and pretend that some arbitrary
feature took care of it. But when has sloth ever excused negligence or
recklessness?
>>>> Are you familiar with Date's various _Writings..._ books? He and
>>>> Darwen and others have demonstrated that null causes great damage.
>>>
>>> I don't need them to postulate it as I've seen it first hand. My
>>> opinion of Date mainly and Darwen to a much lesser extent (more by
>>> association than real research) is that whilst they have taken a pot
>>> shot at a low flying albatross, they haven't come up with anything
>>> even close to better.
>>
>> I disagree. They have correctly identified that missing information as
>> of yet has no theory to address it.
>
> That is a trivial conclusion! Where's the beef? You don't need to be a
> luminary to get this far - do you?
That's a preamble not a conclusion. Duh.
>> While I disagree with some of their ad hoc attempts to address it
>> differently than null, I suggest the RM -- without any special feature
>> for missing information -- already handles it as well as we can until
>> someone establishes a valid theory addressing missing information.
>>
>> Null takes a bad situation and makes it worse. It does harm. Removing
>> it improves our lot.
>
> I'm all eyes! I'm happy to consign null to oblivion if you give me a
> _credible_ solution which means it must meet ES+C to accommodate my
> limited analytical abilities.
I already have: the relational model. It handles missing information as
well as or better than any other formalism at this time.
>>> Given the lesser evil option I expect to rely on skilled
>>> practitioners to mitigate the risk of that damage arising. Sadly
>>> they don't grow on trees!
>>
>> All the more reason to make simple queries easier to express correctly
>> so casual users do not have to waste the time of skilled practitioners
>> for very common, mundane queries.
>
> I can relate to that - but I for one don't see your mundane queries as
> in the problem domain. Viable practitioners can design RM compliant
> systems using SQL if required. The real issue is solving the difficult
> queries - something which D+D skate glibly over as I pointed out.
You seem to object to describing data using more simple sentences and
fewer complex sentences where the sentences are predicates.
Can you offer an example of a difficult query and describe how
decomposing the relations as presented on that slide will make the query
too difficult for a skilled practitioner?
>>>> Nulls attempt to address missing information but do so with no basis
>>>> in theory. I suggest that the null elixir only offers the illusion
>>>> of power:
>>>> http://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD898.html
>>>
>>> I understand your view. For the record mine is that null is no elixir
>>> - more like Cod Liver Oil and there ain't no illusions when
>>> swallowing that stuff.
>>
>> If one takes the average age of a group of people where some of the
>> ages are unknown, then the average is unknown. With a relational dbms,
>> I can model the ages so that it returns the correct result, unknown.
>
> I can cope with that - I would have no problem being forced to write
>
> "select avg(age) from table where age is not null"
>
> to get the crappy statistic that it is if the user demanded it. But I
> thought you wanted to eradicate the nulls period?
I agree it is no problem to write the query to get the average ages
where the age is known. Using null, how does one write the query to get
the correct result, ie. the average is unknown ?
Null reduces expressibility. It is an elixir that prevents one from
expressing inconvenient truths, but those truths do not go away. Always
getting a finite numeric answer is merely an illusion of power.
>> When the user gets the result, the user has to ponder what that means
>> and how to proceed. If the user discovers that back in the old days
>> nobody bothered to record birthdates, the meaning is different than if
>> the ages are unknown because some of the people are fetuses as of yet
>> unborn.
>
> You are taking on too much methinks - if a mug user wants to buy
> birthday presents for fetii why should the RM be saddled with saving him
> from his own stupidity. Better IMO to focus on those who want to be saved.
Where did I say anyone was buying mugs? Your straw man is pointless;
stick to what I said. I have postulated two users issuing similar
queries in very different circumstances where the correct answer to an
average is unknown.
Using null, how does one express the query such that it gives the true
and correct result that the average is unknown?
>> Null is less expressible than the RM because it obviates the
>> possibility of returning the correct result. The result it returns is
>> incorrect and in the cases mentioned above is not even approximately
>> correct, but the user has no alert to the problem.
>
> Unskilled users yes
Unskilled users. Skilled but hurried users. Skilled but fallible users.
In other words: the universal set of users.
Compile-time error messages are better than run-time error messages are
better than no error messages with obviously incorrect results are
better than no error messages with wrong but seemingly correct results.
In the example given, null moves the error all the way down the list to
"wrong but seemingly correct results".
>> If that is not an illusion of power, I don't know what is. As a
>> solution for the problem of missing information, null is an elixir.
>> Since your earlier evasiveness has revealed your lack of intellectual
>> honesty, I will dismiss your denials as groundless.
>
> Ah well we all have crosses to bear - suffice to say there are no
> illusions on my part.
Suffice to say I have demonstrated otherwise.
>>> That is how I would characterise "D". On the theory side I am in a
>>> prolonged contemplation on the missing dimension in SQL (as compared
>>> to the RM) which is the temporal capability. I have made what I
>>> consider to be some progress but it is premature to discuss publicly
>>> lest I end up wearing lots of egg, suffice to say the null thang has
>>> a parallel in temporal matters. BTW I don't rate Date & Darwens
>>> offering on this either, nor FWIW much of the Snodgrass et al stuff
>>> that preceded them.
>>
>> Yes, well, get back to us when you have something substantive to offer
>> that won't leave egg on your face.
>
> No problem. In the meantime I am happy for you to advance something
> more than a simple change to the behaviour of avg().
You are an idiot. Plonk.
Bob Badour
> Frank Hamersley wrote:
>
>>I can cope with that - I would have no problem being forced to write
>>
>>"select avg(age) from table where age is not null"
>>
>>to get the crappy statistic that it is if the user demanded it.
>
>
> I dunno. If you have a whole lot of people and most of them
> have their ages filled in and a few don't, are you ever going
> to want to ask, "what is the average age", since the answer
> will always be "unknown."
The naive user will ask the query and get a surprising result. The naive
user will then have to think about what is really desired. If an unknown
answer is unacceptable, the user will have to make the effort to
discover the missing ages.
If the user can accept the average of the known ages but has to adjust
some other aspect of the application to account for the difference, the
user can make both adjustments.
The elixir of null keeps the user blissfully ignorant of the mistake
while magnifying a simple and easily corrected mistake beyond all
recognition.
Doesn't seem much use to me.
I suppose we should change square root to give us the root of the
absolute value when dealing with integers, eh? Doesn't seem much use to
ask for the root of a negative, or does it?
By the same logic, I suppose one can omit the ", x != 1" in a proof when
simplifying:
(x-1)/(x-1) to 1 ? Your teachers were no doubt just being persnickity.
> If you want to know if any of them are unknown, you could
> ask that specifically.
But what would ever induce the naive user to ask that? I suppose one
could ask whether any of the integers for which one evaluates the square
root are negative. But if one asks for the square root and gets an
integer, why would anyone think to dig further?
> But if you want to know the average
> age, then you want to know the average of the data you have;
In the example I gave, the average of the data the user had was truly
unknown. The correct answer was unknown. Wouldn't the user want to know
the correct answer? Or are you saying that the purpose of the dbms is to
guarantee incorrectness?
> you're not asking about the data you don't have because
> you don't have it.
I disagree. As I said, I could model the data to state explicitly that
the ages are unknown. That, then, is the data the user has.
> The only useful query in there is "give
> me the average age for the data I have";
Yes, I agree, and the correct answer is unknown.
> why should we
> make the way you ask for that longer winded than other,
> never-useful queries?
You have not established that the queries are never useful. I have
already established the counter examples.
> And how "crappy" is that statistic anyway? Probably not
> at all crappy. It's probably exactly what you want.
Actually, the probability that the incorrect result is desired is zero
in the examples I gave. I already established that. Why would you waste
everybody's time with this straw men?
> The idea of null as something that taints everything it
> touches doesn't seem useful or practical to me.
Null isn't useful or practical. Duh.
Bob Badour
If one is talking about the inception, one would have to test the
hypothesis on the first release of visicalc. I do not consider one
product repeating the errors of another product valid argument in any case.
Marshall Spight
> Marshall Spight wrote:
> >
> > touches doesn't seem useful or practical to me.
>
> I fully understand the sentiment however in cases like this I prefer
> arrangements that retain flexibility for the (awake) programmer and
> provide a form of simple clarity.
I agree, however I think what I described better meets these
criteria than what you described! As far as flexibility goes,
you can always put a CASE statement around the value
if you need to.
> i.e. if there is one null the avg() is null.
I can't ever imagine a situation where this would be useful
or desirable. Anyone?
Let's say I had a customer database with 1000 customers in
it, and I have the age of 999 of them, and one null. Let's say
I hire an analyst because I want to study some things about
my customer database. Maybe I want to do some TV advertising,
so I want to know some things about the demographics of my
customers. I ask the analyst, what is the average age of my
customer base, and what does each decile look like? The
analyst comes back later, and says, the average age of
our customer base is unknown. For each decile, there are
100 people, and the average of each decile is unknown,
and the range of ages in each decile is unknown. I'm going
to fire that analyst and get a good one.
> This simplistic approach means any stray nulls creeping into a dataset
> where none are expected will not go undetected if inadequately
> constrained queries are framed.
I don't see this as an issue. The schema controls whether nulls
are allowed or not; if they are not allowed, they won't be there,
and if they are allowed, they are pretty much certain to be there.
And again, if for some strange reason you want to query for
that, you can.
Marshall
Marshall Spight
>
> PMFJI, I thought it might be useful to point out that spreadsheets have
> had to address this problem since their inception. As far as I know
> they, by default, ignore empty cells when averaging ranges, as opposed
> to dropping out with an error. As such they view the empty cell as as
> not existing in the range at all. If all cells are empty then no range
> exists and an error results.
Interesting.
I just fired up Excel 2003. I entered two columns of numbers, and
left one cell empty in each column. Then I set the formula for the
third column to be col1 + col2. Then I got the sum of the first two
column. It behaved exactly as I propose: missing values were
ignored, both on the vertical sum and on the horizontal sum.
This preserves the SUM(A) + SUM(B) = SUM(A+B) property
as well.
Would anyone care to propose a plausible use case for not
wanting this behavior?
Marshall
Gene Wirchenko
<marshal...@gmail.com> wrote:
>Frank Hamersley wrote:
>>
>> I can cope with that - I would have no problem being forced to write
>>
>> "select avg(age) from table where age is not null"
>>
>> to get the crappy statistic that it is if the user demanded it.
>
>I dunno. If you have a whole lot of people and most of them
>have their ages filled in and a few don't, are you ever going
>to want to ask, "what is the average age", since the answer
>will always be "unknown." Doesn't seem much use to me.
>If you want to know if any of them are unknown, you could
>ask that specifically. But if you want to know the average
>age, then you want to know the average of the data you have;
>you're not asking about the data you don't have because
>you don't have it. The only useful query in there is "give
>me the average age for the data I have"; why should we
>make the way you ask for that longer winded than other,
>never-useful queries?
>
>And how "crappy" is that statistic anyway? Probably not
Obviously, we do not know.
>at all crappy. It's probably exactly what you want.
Possibly, it is near the actual value. Since it is only a guess,
who knows?
>The idea of null as something that taints everything it
>touches doesn't seem useful or practical to me.
It is quite useful. It means you do not have enough data yet.
If you are guessing, at least admit that you are doing so.
Try filling out a tax return with one piece of data missing. Do
you think that your government will go for "It's probably exactly what
you want."?
Sincerely,
Gene Wirchenko
Gene Wirchenko
<marshal...@gmail.com> wrote:
[snip]
>Let's say I had a customer database with 1000 customers in
>it, and I have the age of 999 of them, and one null. Let's say
>I hire an analyst because I want to study some things about
>my customer database. Maybe I want to do some TV advertising,
>so I want to know some things about the demographics of my
>customers. I ask the analyst, what is the average age of my
>customer base, and what does each decile look like? The
>analyst comes back later, and says, the average age of
>our customer base is unknown. For each decile, there are
>100 people, and the average of each decile is unknown,
>and the range of ages in each decile is unknown. I'm going
>to fire that analyst and get a good one.
So would I. I would also fire a consultant who represented
incomplete data as being complete. I want to see the assumptions,
say:
"We took your customer database as of 2006-04-01 and analysed it
by age as requested. Of the 1000 rows, one did not have age data, so
we discarded it from consideration." etc.
If the analysis had non-age-related parts, then would that row be
considered? Again, I would read the assumptions.
[snip]
Sincerely,
Gene Wirchenko
Bob Badour
> Frank Hamersley wrote:
>
>>Marshall Spight wrote:
>>
>>>The idea of null as something that taints everything it
>>>touches doesn't seem useful or practical to me.
>>
>>I fully understand the sentiment however in cases like this I prefer
>>arrangements that retain flexibility for the (awake) programmer and
>>provide a form of simple clarity.
>
> I agree, however I think what I described better meets these
> criteria than what you described! As far as flexibility goes,
> you can always put a CASE statement around the value
> if you need to.
Since null reduces expressibility relative to the RM, the premise above
is false. Having no ability to express an important concept is neither
flexible nor powerful, and null reduces one's ability. Pretending that
this has no practical consequence is intellectually dishonest.
I can only surmise Frank uses some special sort of Orwellian logic. Not
Orwellian in the sense that Orwell would ever use it himself, but in the
sense of the so-called logic Orwell described so well. Frank's reasoning
is fallacious as already established here.
>> i.e. if there is one null the avg() is null.
>
> I can't ever imagine a situation where this would be useful
> or desirable. Anyone?
I will be kind and assume your lack of imagination results from imbibing
too much of the elixir itself.
Since when are correct answers neither useful nor desirable? Do you
prefer your employees give you incorrect answers to avoid admitting when
they do not know an answer?
> Let's say I had a customer database with 1000 customers in
> it, and I have the age of 999 of them, and one null.
Let's suppose instead you are a direct marketer whose database records
facts on 25 million customers. Let's further suppose your demographic
information is incomplete based as it is on self-reported questionnaires.
Let's suppose the women leave the sex field blank more often than men
due to feelings of vulnerability (and women living alone more often than
women in general.) Let's also suppose that women between the ages of 35
and 55 omit their birthdates more often than any other cohort due to
reasons of vanity.
While you may not know it, half of the people who left both the sex and
birthdate blank on the questionnaire are women between the ages of 35
and 55 living alone.
You send out a test mailing for a product that makes it very easy to fix
or replace leaky faucets. You get an unheard of 10% response rate among
women between the ages of 35 and 55 living alone which is a 5% response
rate among those who left both sex and birthdate blank and a 1.5%
response rate overall.
Your regression analysis indicates age and sex correlate highly with
purchasers, and combined they correlate even more.
You say: "Great! What are the min, max and average ages of purchasers?
What percentage are men vs. women?"
select min(today-birthdate), max(today-birthdate), avg(today-birthdate)
, sum(case when sex='male' then 1 else 0 end) * 100 / count(*)
, sum(case when sex='female' then 1 else 0 end) * 100 / count(*)
from campaign_responders;
Your database tells you your max age is 42, the min age is 22, the
average age is 27, men were 80% of your responders and women were 20%.
You issue a few more queries to refine things and you decide to send out
a massive mailing to 50 million men aged 24 to 35 from every list you
can get your hands on. You spend millions and lose your shirt.
Your competitor uses a product that gives a correct answer, sends out a
massive mailing to 25 million people who left both fields blank from
every list he can get his hands on. He sells over a million units for a
$10 million dollar profit while expanding his database by a million names.
Let's say
> I hire an analyst because I want to study some things about
> my customer database. Maybe I want to do some TV advertising,
> so I want to know some things about the demographics of my
> customers. I ask the analyst, what is the average age of my
> customer base, and what does each decile look like? The
> analyst comes back later, and says, the average age of
> our customer base is unknown. For each decile, there are
> 100 people, and the average of each decile is unknown,
> and the range of ages in each decile is unknown. I'm going
> to fire that analyst and get a good one.
As would I. He should say: "How do you want me to handle the unknown
ages?" Or: "Only 1 age in your database was unknown. That will not have
a significant impact on the following deciles, which I have rounded to
the nearest year in any case:..."
>>This simplistic approach means any stray nulls creeping into a dataset
>>where none are expected will not go undetected if inadequately
>>constrained queries are framed.
>
> I don't see this as an issue. The schema controls whether nulls
> are allowed or not; if they are not allowed, they won't be there,
> and if they are allowed, they are pretty much certain to be there.
>
> And again, if for some strange reason you want to query for
> that, you can.
But how do you ask it to deliver the correct average? Or the correct
minimum? Maximum? Sum? Null simply prevents one from asking the
question. Hence the illusion of power.
David Cressey
"Marshall Spight" <marshal...@gmail.com> wrote in message
news:1146078267.0...@g10g2000cwb.googlegroups.com...
Good point.
Repeat the experiment with avg. The results are even more interesting than
sum.
Bob Badour
> JOG wrote:
>
>>PMFJI, I thought it might be useful to point out that spreadsheets have
>>had to address this problem since their inception. As far as I know
>>they, by default, ignore empty cells when averaging ranges, as opposed
>>to dropping out with an error. As such they view the empty cell as as
>>not existing in the range at all. If all cells are empty then no range
>>exists and an error results.
>
> Interesting.
>
> I just fired up Excel 2003. I entered two columns of numbers, and
> left one cell empty in each column. Then I set the formula for the
> third column to be col1 + col2. Then I got the sum of the first two
> column. It behaved exactly as I propose: missing values were
> ignored, both on the vertical sum and on the horizontal sum.
> This preserves the SUM(A) + SUM(B) = SUM(A+B) property
> as well.
Then your spreadsheet behaves differently from your database.
My spreadsheet alerts me to a problem when I try to enter A+B where
either is blank. Did yours not alert you to any potential problems?
Marshall Spight
> >
> >The idea of null as something that taints everything it
> >touches doesn't seem useful or practical to me.
>
> It is quite useful. It means you do not have enough data yet.
> If you are guessing, at least admit that you are doing so.
The declaration of the attribute as "nullable" in the schema is
exactly the admission you desire.
> Try filling out a tax return with one piece of data missing. Do
> you think that your government will go for "It's probably exactly what
> you want."?
Most tax forms that I've seen have lots of fields that are allowed
to be left blank. So yes, that would be fine.
Marshall
Marshall Spight
>
> Since null reduces expressibility relative to the RM,
Consider a language, let's say SQL:1992, but with all references
to NULL removed. Call it L-N. Consider the same source language
but without removing NULL; call it L+N.
For every expression that can be written in L-N, there exists
an identical expression in L+N. Furthermore, there exist
expressions in L+N that cannot be written in L-N; namely
those that use NULL. Hence, L+N is strictly more expressive
than L-N.
Let us say you manage to demonstrate an encoding for L-N
such that expressions in L+N that use null can be expressed
in L-N. All that would do is show that they are equally
expressive.
Marshall
Marshall Spight
> > left one cell empty in each column. Then I set the formula for the
> > third column to be col1 + col2. Then I got the sum of the first two
> > column. It behaved exactly as I propose: missing values were
> > ignored, both on the vertical sum and on the horizontal sum.
> > This preserves the SUM(A) + SUM(B) = SUM(A+B) property
> > as well.
>
> sum.
I was thinking about this just before you suggested it, and it occurred
to me that the average of an empty set should produce the same
result as a divide by zero. Sure enough, if you ask excel what the
average of three empty cells is, it says "#DIV/0!".
Using average in the grid does *not* have the property
(AVG(A) + AVG(B)) / 2 = AVG(A+B). That property
won't hold unless A and B have the same cardinality,
which they won't (necessarily) if A or B is allowed to
be empty. We can generalize this to say that
a fold of a fold won't necessarily return the same
results as a flattened fold.
Marshall
Gene Wirchenko
<marshal...@gmail.com> wrote:
>Gene Wirchenko wrote:
[snip]
>> Try filling out a tax return with one piece of data missing. Do
>> you think that your government will go for "It's probably exactly what
>> you want."?
>
>Most tax forms that I've seen have lots of fields that are allowed
>to be left blank. So yes, that would be fine.
They are then usually presumed to be zero. What if you left off
your gross income because it was unknown (due to your employer not
providing you with the appropriate information slip)? "It's probably
exactly what you want."? Not likely!
Sincerely,
Gene Wirchenko
Marshall Spight
>
> What if you left off
> your gross income because it was unknown (due to your employer not
> providing you with the appropriate information slip)?
Then that attribute is declared not nullable.
I think you example supports my ideas quite well.
Marshall
Bob Badour
> Bob Badour wrote:
>
>>Since null reduces expressibility relative to the RM,
>
> Consider a language, let's say SQL:1992,
Let's not. SQL:1992 is not relational. It's lack of proper domain
support alone would lead you to an entirely incorrect conclusion.
Bob Badour
I guess it's just too bad that more than twenty years of work by
multiple people so thoroughly crushes your ideas, then.
mAsterdam
> Marshall Spight wrote:
>
>> Bob Badour wrote:
>>
>>> Since null reduces expressibility relative to the RM,
>>
>>
>> Consider a language, let's say SQL:1992,
>
>
> Let's not. SQL:1992 is not relational.
This is irrevant to the question.
Marshall Spight
>
> This is irrevant to the question.
Indeed. The basic equation isn't sound, and there's no
getting around that.
Start with a language L. Add feature F to get language L'.
L' is less expressive that language L. Solve for F.
For all L: result is the empty set.
(Note that I do not say "null.")
Marshall
Marshall Spight
not a theoretical one per se. The semantics of SQL's
null are well-defined, if rather clunky. Likewise, my
empty-set semantics are quite well established and
theoretically sound. The question is, which one leads
to the most useful software? I propose that a piece
of software that refuses to run calculation on data you
do have because of data you don't have is less useful
that one that is not so pedantic. Since this is a design
issue, the only way to validate that assertion is through
HCI testing, which I don't expect either side to perform.
I also observe that argument-by-naive-user is not one
I consider very strong, unless the software is designed
specifically for naive users. (Which is clearly no the case
for the DBMS category.) Nonetheless, it is interesting that
excel, which is probably the math-oriented software with
the largest penetration into the broad market, works the
way I propose.
Marshall
Gene Wirchenko
<marshal...@gmail.com> wrote:
>It is worth noting that this is a *design* issue and
>not a theoretical one per se. The semantics of SQL's
>null are well-defined, if rather clunky. Likewise, my
>empty-set semantics are quite well established and
>theoretically sound. The question is, which one leads
>to the most useful software? I propose that a piece
>of software that refuses to run calculation on data you
>do have because of data you don't have is less useful
>that one that is not so pedantic. Since this is a design
>issue, the only way to validate that assertion is through
>HCI testing, which I don't expect either side to perform.
Let us make the assumptions explicit.
For example, C will quite happily do integer calculations that
cause overflow and not indicate any sort of error. (The result is
undefined.) That makes it less useful and is one reason why I do not
use it much.
In the database arena, I want to know when my data is not up to
snuff, just as I prefer seeing "Division by zero error" to getting
nonsense output.
>I also observe that argument-by-naive-user is not one
>I consider very strong, unless the software is designed
>specifically for naive users. (Which is clearly no the case
>for the DBMS category.) Nonetheless, it is interesting that
>excel, which is probably the math-oriented software with
>the largest penetration into the broad market, works the
>way I propose.
Not checking assumptions is something that I expect with naive
users. There are quite a few of these users. Depending on the
domain, it might well include me. I would prefer to have guardrails.
To me, "That operation is invalid because..." is better than a
questionable answer. I can then correct the error and try again.
How fast do you want your wrong answers?
Personally, I can wait indefinitely for wrong answers.
Sincerely,
Gene Wirchenko
Bob Badour
> It is worth noting that this is a *design* issue and
> not a theoretical one per se.
Which is why one should leave it to the designer. Give me a good logical
model to use, and if I wish the behaviour that null purports to give, I
will design it that way. Quite easily, I might add. And without the
ensuing internal damage to all functions of the dbms.
> The semantics of SQL's
> null are well-defined, if rather clunky.
You and I use differing definitions of "well-defined".
> Likewise, my
> empty-set semantics are quite well established and
> theoretically sound. The question is, which one leads
> to the most useful software? I propose that a piece
> of software that refuses to run calculation on data you
> do have because of data you don't have is less useful
> that one that is not so pedantic.
Whoever posited such a stubborn creature? Certainly not I. Requiring
someone to make an informed decision and an explicit statement about
what to do when confronted with missing information is not at all the
same as refusing to calculate.
Since this is a design
> issue, the only way to validate that assertion is through
> HCI testing, which I don't expect either side to perform.
What makes you think I have not performed those tests? I have directly
observed hundreds of dbms users interacting with dbmses. I have been
paid large sums of money to 'solve' problems caused by nulls and
duplicate rows in existing designs. I have watched "hundred-million
dollar+" projects succeed or fail over such nonsense.
I witnessed a hundred-million dollar family business that dominated its
market fail over such nonsense.
> I also observe that argument-by-naive-user is not one
> I consider very strong, unless the software is designed
> specifically for naive users.
I include talented application programmers among the naive users of dbmses.
Bob Badour
You have a faulty assumption. You assume that feature F has no effect on
the set of existing features of L. The assumption is false, as is your
conclusion.
Gene Wirchenko
<bba...@pei.sympatico.ca> wrote:
[snip]
>I witnessed a hundred-million dollar family business that dominated its
>market fail over such nonsense.
Can you provide a case study of this?
[snip]
Sincerely,
Gene Wirchenko