| |||||||||||||
A report from OpenSQLCampA report from OpenSQLCampPosted Nov 4, 2010 1:02 UTC (Thu) by ringerc (subscriber, #3071)In reply to: A report from OpenSQLCamp by alankila Parent article: A report from OpenSQLCamp
Null handling isn't too bad if you're not dealing with brain-dead databases where you have to severely limit the used feature set. You can use "NOT (A IS DISTINCT FROM B)" to cover equality and nullity in one expression. It's a wee bit verbose, but better than a properly null-safe equality comparison, which is just horrid. I'm of two minds on NULL. On one hand, it's semantically different to the null/NULL/None/undef/whatever in most programming languages, and behaves differently. On the other hand, it's a really useful concept that's intellectually appealing. It's such a PITA to actually work with that I'm not sure it's worth it, though, especially once you get to the inconsistencies in its application in various parts of the spec.
(Log in to post comments)
A report from OpenSQLCamp Posted Nov 4, 2010 11:45 UTC (Thu) by alankila (subscriber, #47141) [Link]
Yeah, NULLs sound useful at first, but the only real place where I use them today is for indicating a missing value in a numeric field. For string fields, I find that empty strings are good substitutes for NULLs, and many dates, especially those that mark some start and end epoch can be set to year 0000 or year 9999 initially instead of NULL depending on what is the semantically most useful way to view the value.
|
|||||||||||||