Re: Arbitrary Constraints

From: Dawn M. Wolthuis <dwolt_at_tincat-group.comREMOVE>
Date: Wed, 27 Oct 2004 09:20:53 -0500
Message-ID: <cloasn$dfe$1_at_news.netins.net>


"Tony Andrews" <andrewst_at_onetel.com> wrote in message news:1098882637.945531.272870_at_z14g2000cwz.googlegroups.com...
> Laconic2 wrote:
> > There is a legitimate design question around where you want to
> enforce
> > business rules.
> > And it's possible that the right answer might be "in more than one
> place".
> >
> > I can easily see situations where the UI enforces a "field not blank"
> rule
> > on the user, and the database enforces a
> > "column not null" rule on the incoming data, even though this might
> be
> > seen as redundant.
>
> Agreed - that is exactly the sort of constraint I would expect to see
> implemented in both places:
> 1) By the DBMS - because the DBMS wants to ensure the integrity of the
> data regardless of source
> 2) In the UI - redundantly, because the DBMS would reject anyway; but
> it has the advantages that (a) the user gets informed immediately, on
> exit from the field, rather than only when the data has been submitted,
> and (b) we avoid the expense of a wasted "round trip" to the DBMS.

You want validation of all data coming in from a UI, including ensuring that invalid data cannot be entered by using drop-down lists and such when there is a validation table (a constraint) for an attribute. Additionally, if the data are entering the system from a web service or other "batch" system (yup, old terminology) then we also want the data validated up front to get a turn-around back to the sending software.

Then if there were a way to ensure that only validated data made its way to the database services (CRUD), there would be no reason to double up the validation, right?

> The important consideration that is so often overlooked by people with
> a "developer" mindset and not a "database" mindset is that applications
> come and go, come and go, but the data is there "forever".

You can probably guess that I'm one of "those" people, but I do understand that the data are there for multiple applications, which each application is only doing it's thing. That's the reason I suggest that the CRUD services reject any requests that do not come through proper channels. Alternatively, at the very least the constraint specifications used for the UI and the web services and the database should be the very same. We don't want to have one person coding a constraint that the status code must come from a status table at the database level, another coding it in a web service and another hard-coding it for a drop-down box (I suspect this happens more than one might think).

> Right now,
> everyone is re-building their old apps using Java; in 5 years time it
> may be C#.NET or some as yet unknown super-language. Also, even while
> the current UI exists, there is often a push for new alternatives:
> web-based applications, mobile phone-based applications maybe; a batch
> process that receives XML by email and populates the database;
> whatever. The more robustly constraints are enforced by the DBMS, the
> easier and less dangerous it is to allow these UI upgrades and
> alternatives.

There are systems that need this type of control, but I think our industry could move forward faster if we get those constraint specs out of the proprietary database language and into services that can be used by any aspect of any application that needs to have the constraint logic, including the crud services. And, again, maybe if we can ensure that the crud services for the database only function on data that have already been validated, then we won't have to re-validate data, even though our system will still need to employ RI constraints at that time.

--dawn Received on Wed Oct 27 2004 - 16:20:53 CEST

Original text of this message