| Subject | Re: [firebird-support] Firebird mentioned at www.dbdebunk.com :-) ... Nulls in Unique Indices |
|---|---|
| Author | unordained |
| Post date | 2003-11-22T01:45:56Z |
Heh. Dbdebunk is fun, but their current stance on NULL is somewhat ... 'odd', at least. Note that I
just got, for my birthday (my girlfriend's a bit geeky,) their book "Foundation for
Object/Relational Databases -- The Third Manifesto". It's an interesting read, and I think Firebird
could grab some useful stuff from it. (Notably updatable views that include more than one table?)
Still ...
- While they refer to Codd as proof that NULL is bad, Codd included NULL in his 12 (or 13, if you
count rule 0) rules for what constitutes a true RDBMS. It simply states that they must be handled
consistently. It does not outlaw them, unless his rule about NULL is in violation of another rule
(the information principle.) And then we're using a set of rules that isn't consistent.
- They have stated that the "relational model" evolves, even though they -also- state that it needs
no extension, no correction, no subsumption, and above all, no perversion. Disagreement doesn't
mean there's no good or right answer, but they've been rather unclear on this point. (Not in the
force of their statements -- only the part about a perfectly logical system being modified ...)
- Hugh Darwen's presentation from a few months ago (on thirdmanifesto.com, I believe) basically
says this about getting rid of NULL non-values:
a) define a separate table for each attribute that might not always be known, using the same PK as
the table the attribute was originally in
b) only store tuples in that table when that attribute has a known value
c) when you want to do something like a left join, do an inner join unioned with that which
couldn't be joined (which he suggests involves joining to a table that contains just the PK, and is
named something like *_unk,) and replace the missing values with some other value, which must be
part of the same domain as the values that you're otherwise pulling. rather than using NULL, you
must replace the missing information with another valid value, like ''.
I've asked Hugh why you would go to the trouble of doing this when, in the end, you're going to
replace the missing information with another value from the set -- and could have done so from the
start. Just store '' in the original table, and don't bother splitting it (if that's the value you
intend to use to mean "i don't know".) I've yet to get a response other than "i'm too busy right
now", so I'm sorry to say I can't contribute a more useful answer.
In the end, they'd probably be okay with us defining domains which contain one entry that is not
NULL, but is the value used to indicate we don't know what the value is. So long as it's not system-
defined, and you go to the trouble of deciding how to handle missing information yourself. I'm not
sure what they intend to do with the NULL != NULL rule. If it's a logical necessity to have that
rule for unknown values, then NULL seems just as good as any other domain value, no? Some people
understand it and like it, some people understand it but don't like it, and ... then there's the
rest.
But hey, Firebird got mentioned. Woohoo!
-Philip
---------- Original Message -----------
just got, for my birthday (my girlfriend's a bit geeky,) their book "Foundation for
Object/Relational Databases -- The Third Manifesto". It's an interesting read, and I think Firebird
could grab some useful stuff from it. (Notably updatable views that include more than one table?)
Still ...
- While they refer to Codd as proof that NULL is bad, Codd included NULL in his 12 (or 13, if you
count rule 0) rules for what constitutes a true RDBMS. It simply states that they must be handled
consistently. It does not outlaw them, unless his rule about NULL is in violation of another rule
(the information principle.) And then we're using a set of rules that isn't consistent.
- They have stated that the "relational model" evolves, even though they -also- state that it needs
no extension, no correction, no subsumption, and above all, no perversion. Disagreement doesn't
mean there's no good or right answer, but they've been rather unclear on this point. (Not in the
force of their statements -- only the part about a perfectly logical system being modified ...)
- Hugh Darwen's presentation from a few months ago (on thirdmanifesto.com, I believe) basically
says this about getting rid of NULL non-values:
a) define a separate table for each attribute that might not always be known, using the same PK as
the table the attribute was originally in
b) only store tuples in that table when that attribute has a known value
c) when you want to do something like a left join, do an inner join unioned with that which
couldn't be joined (which he suggests involves joining to a table that contains just the PK, and is
named something like *_unk,) and replace the missing values with some other value, which must be
part of the same domain as the values that you're otherwise pulling. rather than using NULL, you
must replace the missing information with another valid value, like ''.
I've asked Hugh why you would go to the trouble of doing this when, in the end, you're going to
replace the missing information with another value from the set -- and could have done so from the
start. Just store '' in the original table, and don't bother splitting it (if that's the value you
intend to use to mean "i don't know".) I've yet to get a response other than "i'm too busy right
now", so I'm sorry to say I can't contribute a more useful answer.
In the end, they'd probably be okay with us defining domains which contain one entry that is not
NULL, but is the value used to indicate we don't know what the value is. So long as it's not system-
defined, and you go to the trouble of deciding how to handle missing information yourself. I'm not
sure what they intend to do with the NULL != NULL rule. If it's a logical necessity to have that
rule for unknown values, then NULL seems just as good as any other domain value, no? Some people
understand it and like it, some people understand it but don't like it, and ... then there's the
rest.
But hey, Firebird got mentioned. Woohoo!
-Philip
---------- Original Message -----------
> http://www.dbdebunk.com/page/page/772081.htm------- End of Original Message -------
>
> With regards,
>
> Martijn Tonies
> Database Workbench - developer tool for InterBase, Firebird, MySQL & MS SQL
> Server.
> Upscene Productions
> http://www.upscene.com