Subject Re: [Firebird-Architect] NOT UPDATABLE fields
Author Dmitry Yemanov
"Adriano dos Santos Fernandes" <adrianosf@...> wrote:
> > What Adriano outlined is an application requirement, not a database
> > requirement.
> I don't agree.
> 1) It's a very common business rule that many types of applications can
> benefit from.

The words "very" and "many" are questionable, but I see your point.

> 2) The engine can use as a hint to reserve less space for record versions.

I don't agree. This is not a feature the engine should know about.

> 3) The current options cannot be used by tools and applications that do
> metadata inspection.

Should they really be aware of it? To be honest, I didn't see tools
supporting your idea.

> 4) It's more easy to write and more clear to read.

Agreed here, although its value isn't critical.

Personally, I'm with Sean. This reminds me a recent discussion in one
Russian forum regarding update defaults existing in Sybase ASA. The idea is
to have an alternative default clause which is used in update statements,
i.e. when a column is not mentioned in the SET clause and an update default
expression is defined for this column, it's being applied automagically. Is
it a useful feature? Perhaps, for some logging scenarios. But my opinion was
that our triggers is exactly what's required for this task. The opponent
argued that a trigger-based solution is too slow and confirmed that fact
with performance numbers. But the truth was that the trigger invocation in
ASA is very expensive (no trigger vs empty trigger showed almost 100%
performance difference) whilst ours are quite fast (10% penalty). After that
the only remaining question was the syntax - whether a DDL declaration is
better than a one-line trigger. I'm still not convienced it is. I believe
that Adriano's proposal is very similar to that story, hence I don't think
such a feature is really important. But I don't say a strong "no" either.
Perhaps, we'll need a voting ;-)