Web of Knowledge

dave.autonoma.ca

50 points·thangalin··4 comments

> If a contact does not have an email address, then there’s no corresponding row in the contact_email entity for that particular contact row. As opposed to the account entity, which would most likely use null to represent missing email addresses.

And then you compose a list with email and phone numbers. Have to use a left join not to miss rows and end up with - guess - NULLs for missing emails.

I agree that NULL (in DBs) is a difficult concept to grasp (you loose binary logic) but it’s trying to solve a difficult problem and every solution to that problem has negative parts. Just forbidding NULL values leads to funny workarounds like the mentioned “NULL“-String.

It is nevertheless a good idea to handle NULL situations as much as possible with dedicated reusable code (such as the listed alternatives: default values, deferred creation, options), rather than representing it as a explicit state.

If you allow an explicit NULL state in a data type, every sentence using that type must include checks to handle that exception.

Whereas if you create type definitions capable of handling the exception in their operators, you can use that type and its operators with confidence that all exceptions are handled properly without additional work.

The reads a bit... snappy and back-and-forthy, but it resonated with me a bit. I like that it connects regrets with eventual achievements.

I like the "So it goes" reference -- excellent article btw :)

Reply on news.ycombinator.com