Re: Multiple specification of constraints

"Marshall Spight" <mspight_at_dnai.com> wrote in message news:9wd%b.121916$jk2.526707_at_attbi_s53...
> "Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message
news:c1iq4p$6dp$1_at_news.netins.net...
> >
> > I'm suggesting something rather radical --
> > decouple the constraint specification and validation logic from the
> > database. Does anyone agree?
>
> It is a real issue, but I don't agree with the direction you're taking.
>
> I think the optimal solution here is to have the constraints specified
> declaratively and centrally, but to be able to *additionally* execute
> them remotely, i.e., on the client. That last part, on the client, is
actually
> the least essential place for validation to occur; it's the only one that
> can be omitted. It's always essential to have it enforced centrally, on
the
> server, because clients are typically not running on trusted computing
> bases.
>
I agree they should be specified "centrally" but don't necessarily agree with what you mean by that. If you mean that they should be specified in a way that is tightly coupled with database storage services, I disagree. I would advocate for use of a design that might include an http server with a jvm as the location for all central rules/constraints processing. I certainly wouldn't locate the validation on the client, but might use the Service UI libraries with Jini for distributed computing -- in that case the compiled (to byte code) validation logic is executed on whichever platform it needs to be.

Additionally, I would argue that the user interface is the MOST important place for knowing the constraints so that the user interface can be as intuitive as possible, preferably written so as not to permit any illegal data from even being entered (but where that isn't feasible, at least letting giving the user the opportunity to fix it immediately). The user interface makes a big difference in the accuracy of the information collected.

I forget who wrote up the story of a major retail chain that built a new store in a certain zip code because their data said a lot of people go from that zip to another to go to this chain. They had to close the store for lack of customers. It turnes out that one of the retail clerks didn't like the constant question of what zip code the buyer was in, so she always entered her own to get past that question. Software usability is key to clean data. The GUI having full knowledge of the business rules (validations & all constraints) is critical to a usable GUI. If the validation should be coded only once (which I agree with), it MUST be where it is usable by the user interface routines. And if we apply all integrity logic up front, so that nothing gets past our validation routines into the database CRUD services, then we don't have to have duplicate logic in the database, right?

Another advantage of this approach is that there is not a need for both a DBA who knows one language and an application developer who knows another to either a) cross train so they are both competent in each or b) wait on each other, often not exactly in a "team player" sort of way when a small change is required in an application that requires a change in the type checking.

--dawn Received on Thu Feb 26 2004 - 15:01:01 CET