Hacker News Reader

Comment by jessaustin | Hacker News Reader

If you have a PEOPLE table and some birthdates are unknown, then remove the "birthdate" column and make another table called PEOPLE_BIRTHDATES with a "birthdate" column and a foreign key pointing to PEOPLE. Now your queries can have lots of left joins. The results will still have nulls, however.

View on HN

Which is the reason why you shouldn't write outer joins.

So if we don't know the customer's birthdate we can't serve her? I can imagine a problem with that...

Sigh.

Where have I said any such thing ?

If there's no row for the customer in the joined table, the customer won't show up in an inner join.

Great. Now if you can explain to me where you got the idea that a join (inner or otherwise) is the only possible way to query two tables then we might get somewhere. Because you can also just do two queries. And no, that does not necessarily mean "two roundtrips to the DBMS" (which I know perfectly well is undesirable). There are techniques for avoiding that. Perhaps not in SQL, but that's a reason you should be pressing the vendors to improve SQL. Not for you to agree to the status quo of sticking with the vendors' old bypasses-and-hacks cheating bag.

Haha OK then use a UNION... oh wait we're gonna have NULLs with that too. One suspects you'll also have some vague objection to this point, but if the only way to address that is to wait on somebody to invent an "improved" SQL, one won't worry about it too much.

That "improved SQL" was already defined in the previous century, and has been implemented as well. Your ignorance drips off of every word you write.

E.F. Codd literally designed null into the relational model. I don't think calling someone ignorant is very helpful.

But the demeaning ridicule that gets thrown at me is ?

(BTW I doubt very much that "Codd designed null into the RM". Even his 12 rules mention only "a systemic way to deal with missing information", not "null".)

Reply on news.ycombinator.com