Adriano dos Santos Fernandes wrote:

>Jim Starkey wrote:
>
>
>
>>On reflection, I don't like this feature for two reasons. First, I
>>consider it unnecessary. Constraints exist to protect data integrity,
>>not servce as a censor for application programs.
>>
>>
>>
>Logical data integrity is important too.
>
>

Yes, logical data integrity is important, but integrity is enforced by
"that field can't change" rather than "you can't assign to that field".
The semantic difference is small, but operationally significant. The
difference? A generic tool that fetches all fields then updates all
field on the assumption that assigning the existing value to a field is
an effective no-op will work correctly with a "that field can't change"
rule but fail with a "no assgiments" rule.

>> If you don't want your
>>application to reference a field, don't reference the field.
>>
>>
>>
>Maybe when someone invented NOT NULL other said "if field don't accept
>NULL, don't store NULL in it".
>
>

Not al all parallel. "No null" doesn't mean that you can't assign a
null to field, but only that the field can't be null when the database
performs the update. Again, the purpose is to protect the data, not
tell you how to write programs or triggers.

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376