Jim Starkey wrote:

>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.
>
>

I have no problem with "that field can't change" instead of "you can't
assign to that field".

The only difference is that in UPDATE or in "on before update triggers"
the field can be assigned and the error will be raised only when the
record will be stored and only if the value is different, right?

Do you agree with this proposal?


Adriano