> But an employee can't be car-less twice!
What.
> That's what this change prohibits.
This change prohibits nothing, it allows specifying something (which was a bit complicated to enforce before).
What.
> That's what this change prohibits.
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.
Hence the new constraint.
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.
unique (EmployeeName), unique (EmployeeName, CarID)
And if this is your employee table, you’d have UNIQUE (EmployeeData) and UNIQUE (CarID), and it would do what you want.