Arguably, you might consider that it is a bad design. Perhaps there should be a paycheck table that you can sort by date, instead of a field in the employee table that is updated.

(Of course this is hypothetical, so it is hard to argue use cases)

But a paycheck table does help with the second example because now you don’t need to estimate number of paychecks either. Which will help with unpaid leave or sabbatical situations to give you an accurate number.

But this is what they are getting at with bad design. (Potentially) As far as normalization goes.

I certainly won't argue that people come up with some bad designs! Heaven knows I've dealt with some of them. I just wanted to point out that there are situations where null is perfectly reasonable, even though there are plenty where it surely isn't.

That question doesn't have an answer because there is no elephant on my desk. It can't be represented by any color, the answer needs to indicate that there is no value.

(Specifically, not returning any rows when queried, which is different from null)

There's really no justification to avoid nulls as a principle.

It is hard to model without requirements but you probably need a table for type of desks, another for desk instances with location and another one to many linking table for items/colors.

Why? I like two lamps and no elephants. By normalizing, this new requirement is simple to represent compared to jamming more fields into the desk table.

Or if another person prefers penguins you don’t end up with penguin_color columns.

It is possible the one table design works, but the introduction of nulls is a smell that indicates maybe the design is a problem.

According to my old SQL Server text book (written by the SQL Server team) NULL should be avoided because it as so many different interpretations (I think forty was mentioned).