Re: Are we losing out because of grammars?

[Ken North <ken_north@compuserve.com>]

> > Rules, due to their invocation at a points in time, make inroads into
the
> > "route" (e.g. SQL triggers).  Declarative rules *use* grammar for their
> > definition and depend on "grammar valid" data on which to operate.

> > SQL didn't get basic triggers until 2.0.
[snip
> > uHeck, most people never use triggers.  They just put it somewhere in
> > the application code.
>
> Well ... I'd say that 'constraints' are 'closer'  than 'triggers'.

My apologies for being too busy lately to follow this entire thread. I'll
jump in here at the risk of being redundant.

In the SQL world, there is often a division of labor between database
designer and application programmer. The designer is the one who creates
schemas, expressing constraints and specifying triggers. Skilled designers
look to declarative rules and constraints first, and then use triggers if
constraints are insufficient for what needs to be done.

Using application code to enforce rules, instead of declaring constraints
that are managed by the container (database), leads to versioning problems.
With container-managed constraints, the rules are applied uniformly across
all clients connecting to the container. With rules coded in application
objects, you have to co-ordinate application updates so the rules are
consistent from one program to the next. Different programming languages,
different namespaces, different versions of classlibs -- it can be nasty
trying to stay in sync.

In the XML world, we can now exploit types and constraints, but one question
is whether developers will learn from the SQL experience, i.e., declarative,
container-managed logic solves some of the proliferation/fragmentation
problems that occur with ad hoc application logic.