Re: Declarative constraints in practical terms
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.
> 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.
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