Hacker News new | ask | show | jobs
by galaxyLogic 521 days ago
In Object Oriented Context "null" is useful to indicate that some object doesn't have value for that property.

What's interesting is, do we mean that in our data that attribute has no value? Or do we mean the real-world object represented by the data does not have that attribute?

Does null mean

a) We don't know the value of this attribute for this object, or

b) We do know that there is no value for this attribute in the real-world object represented by our data.

In JavaScript because there is both null and undefined it is easy to assume that undefined means we don't know the value and null means we do know it has no value.

EXAMPLE: The attribute 'spouse'. Some people have a spouse some don't. So what does it mean if the value of the field 'spouse' is null? That we know there is no spouse, or that we don't know who the spouse is if any.

In practical terms we can say null means "We don't know" which includes the case that there is no spouse.

4 comments

> In JavaScript because there is both null and undefined it is easy to assume that undefined means we don't know the value and null means we do know it has no value.

Javascript objects have two kinds of undefined that are both represented by the same value. You have to use another method to see which it is, and I've seen "foo" in this example used for the same thing as "null" in your example:

  >> z = {foo: undefined}
  Object { foo: undefined }

  >> z.foo
  undefined

  >> z.bar
  undefined

  >> z.hasOwnProperty('foo')
  true

  >> z.hasOwnProperty('bar')
  false
This is something you have to account for because the key is still there if you try to remove a value by just setting it to undefined:

  >> Object.keys(z)
  Array [ "foo" ]

  >> for (let k in z) { console.info(k); }
  foo
This is the right way to remove the key:

  >> delete z.foo
  true

  >> z
  Object {  }

  >> Object.keys(z)
But in a _relational_ database lack of spouse would not be modeled with a nullable column "spouse" but rather an absence of a spouse row/relation. Which is very real-world-like.
As a sort of challenge I had an idea of building an app using SQL as a pseudo ECS system where every table was either a 1 column table with only an id or a 2 column table with an id and a value.
And yet when you do a join because you need to actually use that data, the resulting table will have a column with nulls in it. Any way you squeeze it, you need a way to represent empty values for your database to be useful.
An inner join? Then there wouldn't be any nulls.
IDK, do you want to exclude people without a middle name or a second address line when examining a product order list? I'll leave that one for you to decide.
I remember from my databases course at university that NULL means that the database doesn't contain that data, and empty string means that it is known to be empty.
Let's also all be reminded about how Oracle DB doesn't let you insert empty strings, and instead treats them as NULLS even if you gave it an empty string initially.

https://stackoverflow.com/questions/203493/why-does-oracle-9...

That was a fun bug to find out, after having dealt with quite a few other DBs over the years. It was one of those "No, but surely" and "This can't be! This is Oracle!" moments. Found it while porting some old code that needed to store an empty string as being distinct from a NULL in that same column.

That's your professor's opinion, and probably one that does not come from industry experience. Look in 4 different databases and you'll see 9 different conventions. A common one is to have all strings non-null with a default value of empty string. And not all columns are strings; there is no "obviously empty" integer or boolean.
What is the type is something other than a string?

age: null? married: null?

How about Option<bool> for that? In SQL you could have a nullable Boolean column