Re: Declarative constraints in practical terms

"dawn" <dawnwolthuis_at_gmail.com> wrote in message news:1140555731.823399.160020_at_g44g2000cwa.googlegroups.com...
> This is related to a recent exchange related to declarative
> constraints. I know I've worked on it before, but I am still perplexed
> on this one. Here are two common options for handling constraints
> (business rules):

Why ?

> a) declarative constraints: SQL declarations enforced by a DBMS engine

The constraints in a DBMS engine can also be imperative.

> b) metadata + code: metadata specifications plus custom-build
> validation/constraint functions or services written in a general
> purpose language

The constraints outside the DBMS engine can also be declarative.

> Some differences I can see are

> 1) Declarative constraints are coded in the SQL sublanguage while with
> metadata + code, the metadata declarations are simpler, being in the
> form of name=value pairs (e.g. maxValue=100, valTable=MyTable) but
> proprietary code is written.

What matters is when are they enforced.

> 2) The functions combining the data and constraints in the declarative
> case are in well-tested (over time, at least) engines written by a
> database vendor, otherwise often less generic, more specific, functions
> written by whomever whatever team is writing validation routines for
> software services. .

There can also be a well tested constraint engine "outside" the DBMS.

> 3) The functions for validation of data can be used anywhere within an
> application if packaged outside of the dbms, otherwise most of them
> need to be coded at least twice -- once for the dbms and once for use
> in a UI or web service.

They can be written once and packaged anywhere. They can be written once and called anywhere.

> 4) The declarative constraints use the RM, so they work with the
> restrictions of the RM, including 1NF. Because they are written in
> SQL, they use a 3VL whereas using metadata + code, 2VL and non-1NF are
> the norm.

The declarative constraints use any declarative language.

> 5) In the case of declarative constraints, they are necessarily
> employed by any application writing to the database. In the case of
> metadata + code, each organization must determine whether and how to
> technically enforce business rules for all applications or enforce them
> through standards and QA approaches.

Any access to the database should be managed.

> I lean toward not duplicating constraints, coding and maintaining them
> in multiple places and languages, but I understand that someone else
> might choose the other strategy. Whatever choice, it doesn't look
> obvious to me that declarative constraints are better as I gather it
> appears to many others.

Have you ever used any declarative language (except SQL) ?

> This relates to the fact that the RM is not sufficient for writing
> software

Of course. One cannot write software without writing code.

(as mentioned in my current blog entry that I'll again boldly
> advertise as being at http://www.tincat-group.com/mewsings )

I like the picture of Nick with zeros and ones. Where is the bended thinking stone ?

You talked about minimizing the number of impedance mismatches in an application but you missed the point about abstraction layers (low level vs. high level). Received on Wed Feb 22 2006 - 16:33:39 CET