Even Date agrees in his book. He says that the relational model should permit even relation-valued columns. There’s no reason not to.

Conceptually, yes: you should be skeptical of designs that use extraordinarily complex types. But (a) that does not constitute a violation of 1NF; and (b) complex types are certainly useful for attributes in many situations.

I prefer to have access to the full power of a good type system when working with an RDBMS. I’m not suggesting we go down the road of OODBMSs or anything of the sort, but I do think that we should have access to an adequate set of types to describe a business.

Date says that a data type is a “named finite set of values” and that to be a type, the equality operation has to be defined. That is, you can compare any two values in the type and say they are equal or not. That seems like a pretty straightforward basic definition of a data type.

A string or date can be decomposed or transformed, but I would say that such operations yield a different value, not a part of the original value. Just like an integer expression like x+2 yields a different value from x.

I wonder how common it is to enter some specific value in another field that is known to be wrong, and then explaining the real value in the note to CYA. That way, the reports all reflect the lie, but the person who entered it can claim that they entered it correctly.

This is an important point. Asking users why the need notes and how they use them is very enlightening. In my case, I’ve completely re-factored some schema designs to eliminate the need for the note field. The resulting application allows to users to easily identify the set of records that met a criteria that was formally stored as messages in user notes.