I'm totally in agreement with Hugo on this one. But I did flag it for multiple identifiers, while lots of tables have multiple Unique Keys (Boyce-Codd normal form anyone?) it's probably bad form to have multiple surrogate keys. The example you give about Vehicles having multiple keys is a good one but in that case it has multiple DATA keys which are each legitimate references in different contexts for the object. Creating multiple GENERATED keys is probably unnecessarily complex.

But when it comes to NULLS there are just cases where it makes sense. I got that one wrong as I didn't consider the SalesPersonCell column to be a bad null as it shouldn't even be in the table at all. The FulfilmentDate on the other hand is a perfect case where it makes sense to have a single nullable column which is automatic and denotes the state of a record. If the FulfilmentDate is currently NULL the record has just been entered, the Order Entry system doesn't even allow the clerk to enter a value. When the order fulfilment process happens a trigger automatically puts the current date in that field.

Sure you can add an Order State column which shows you if the order has been filled or not but then you introduce a case where the Fulfilment date depends on something other than the primary key. I guess on the other hand if you have other data that the fulfilment process has to store that's an argument for moving the date out of this table completely storing it in that table and if you need to show the date on the orders screen you get it via a JOIN on the Orders PK. But I certainly wouldn't create a table just to store that one piece of data.