Chuck.Phillips@FtCollins.NCR.COM (Chuck.Phillips) (09/24/90)
Having some experience with First Order Predicate Calculus and now learning
Tuple Calculus, I have two stoopid questions, both about NULLs. :-O
References are welcome.
1. Primary keys are forbidden from containing NULLs. To this stoopid
beginner, mere uniqueness _appears_ sufficient. Is the no-NULL restriction
really necessary for a consistant, robust system? If so, why? If not,
what is _gained_ by adding this restriction? Is this mostly to avoid
future _likely_ violations of uniqueness? (i.e. on par with lint spewing
warnings about type mismatches in C programs; it may work today, but you're
asking for big trouble tomorrow)
2. Relations with a NULL operand return NULL, e.g.
TRUE OR NULL = NULL
This stoopid beginner would expect a vaule of TRUE instead of NULL.
For example, a join of a daily temperatures relation for a particular year
with a daily _record_ temperatures relation might yield something like.
TEMP_STATS_1990(Date,Low_Temp,High_Temp,Prev_Record_Low,Prev_Record_High)
("Date" is the primary key.) In formulating a query for all dates with
record high or low temperatures using ordinary math logic, you could use:
(Low_Temp < Prev_Record_Low) V (High_Temp > Prev_Record_High)
in a single _non-optimized_ scan through the table vs. the accepted
(Low_Temp < Prev_Record_Low) U (High_Temp > Prev_Record_High)
using two _non-optimized_ scans through the table and greater temporary
storage requirements. An unoptimized query becomes still more relatively
inefficient when querying for dates with a record high or a record low
temperature excluding days which have both a record high and a record low.
(Pardon the roughness of expression. My keyboard doesn't have backwards
'E's and I don't yet know enough SQL or QUEL to be dangerous.)
Again, is this restriction necessary? If not, what is the gain?
Like the subject says, these are just stoopid beginner's questions. I'm
not complaining, suggesting a change or an alternate calculus. I'm just
trying to understand _why_ things are the way they are.
DISCLAIMER: I alone am to blame for the stoopid questions. I also
apologize in advance if I've just repeated the two most commonly asked
questions for this group. If so, please flame (and explain:-) via email.
Thanks in advance,
--
Chuck Phillips MS440
NCR Microelectronics chuck.phillips%ftcollins.ncr.com
2001 Danfield Ct.
Ft. Collins, CO. 80525 ...uunet!ncrlnk!ncr-mpd!bach!chuckp