Because it’s very common for attributes to be optional but unique if specified e.g. your fleet management might have a 0-1:1 relationship between employees and cars, no car can be associated with 2 employees, an employee can’t have two cars, but any number of employee can be car-less, or car employee-less (lending pool, or cars which have not been attributed yet).
This also fits perfectly well with the normal interpretation / treatment of sql null as “not a value”.
>This change prohibits nothing, it allows specifying something (which was a bit complicated to enforce before).
It allows specifying a constraint - that you can't have two rows with the same values even if one of the values is a NULL. That's prohibiting duplicate NULLs. The change allows you to prohibit duplicate NULLs.
Say you have a table (EmployeeName, CarID). You could do a UNIQUE constraint on those two attributes, but that would still allow:
EmployeeName | CarID
Jeff | 2
Kim | NULL
Kim | NULL
Here, "Kim" is car-less (NULL in the CarID field) twice, which makes no sense.
> It allows specifying a constraint - that you can't have two rows with the same values even if one of the values is a NULL. That's prohibiting duplicate NULLs. The change allows you to prohibit duplicate NULLs.
Sure.
> Here, "Kim" is car-less (NULL in the CarID field) twice, which makes no sense.
The relation makes no sense to start with, it didn’t need duplicate nulls for that.
That's not quite the same, since the previous solution of unique (EmployeeName, CarID) allowed for one employee to have 2 separate cars. You have to use conditional indexes to solve this.
It's a 0-1:1 relationship, so you'd have columns like "name", "email", "car", etc. on the employees table, and "car" might have a unique index (which is probably an ID referencing a "cars" table).
Since employees can only have one car and since a car can only be used by one employee, an unique index is fine, but there may be 20 people that don't have a car so you don't want NULL values to be unique.
Of course there are always ways to work around this, but this is the general idea.
This also fits perfectly well with the normal interpretation / treatment of sql null as “not a value”.