Re: Declarative constraints in practical terms

From: dawn <dawnwolthuis_at_gmail.com>
Date: 22 Feb 2006 08:11:44 -0800
Message-ID: <1140624704.366977.60730_at_g44g2000cwa.googlegroups.com>


x wrote:
> "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.

Yes.

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

Yes. I sketched out two common scenarios.

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

Agreed. I don't mean whose software enforces them (dbms product, proprietary software or whatever), but whether they are enforced at the appropriate points.

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

Most definitely. I like that approach.

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

How and how often is this done? I have seen this in cases where no (few) constraints are enforced within the DBMS and reside in proprietary database services and where the UI or is character or very thin client-based. The same validation routines can be used across the board that way.

> They can be written once and called anywhere.

I'm very interested in this approach. I would like more details. How can I use the validation logic from within JavaScript, for example, for a browser-UI and then again within database update services? (and be database independent, hopefully)

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

Can we have it work so they use any 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.

agreed

> > 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) ?

Only proprietary sublanguages, otherwise SQL is it.

> > This relates to the fact that the RM is not sufficient for writing
> > software
>
> Of course. One cannot write software without writing code.

agreed

> (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 ?

right here

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

One can only fit so much in -- I likely write too much per article anyway, but what is your particular point related to abstraction layers in this regard? You could put it in a comment there to help with completeness if that suits you. Thanks! --dawn Received on Wed Feb 22 2006 - 17:11:44 CET

Original text of this message