I agree. You could just write

select so.* from SalesOrderdetail as so

and get the same result. (with the not null model)

That code would only be written if the developer did not know the data structure, or did not TRUST it. At least the cost of that distrust is very low (optimizer time only).

I think the cost of a FK constraint is in the insert and update side. There is a savings when the developer does not have to worry about detail rows that don't join to the header. That saving exists even without a FK constraint, if the data entry system is trusted to ensure it. But I would tend to constrain the data to ensure that the data entry code continues to work properly.

I think the conclusion that constraints improve performance is not sufficiently proven here.

But this article brought up several good points: 1) Making a FK null where the PK is not null will allow null values to be added that are not constrained. That is an interesting point. It is a good practice to keep the pk and FK are the same, even down to the null/not null constraint.

2) Check for untrusted constraints and correct them, as several of us have already done.

Thank you for a stimulating and informative article.