Re: Multiple specification of constraints

"Eric Kaun" <ekaun_at_yahoo.com> wrote in message news:tjn1c.20849$EI4.8634_at_newssvr31.news.prodigy.com...
> "Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message
> news:c1lk7d$aj4$1_at_news.netins.net...
> > If I understand you correctly, you are actually IN FAVOR OF DUPLICATING
> THIS
> > COMPLEX DATA -- locating it once in the database and again in a
different
> > language in the business rules used by the GUI. Is that correct?
>
> Yes, it's a necessity if you want any assurances. If you only have ONE
> application, with ONE GUI, then you may not have a problem (for now).
>
> And the rules aren't duplicates - not exactly. For example, the GUI sort
of
> needs the DBMS to provide rapidly-changing data like currency exchange
> rates, right?

There are definitely local constraints for specific applications that would not be specified as global constraints. It would be foolish to specify all global constraints in one language and apply them with one data integrity engine, while coding local ones using different tools entirely, I would think. Local constraints are just global constraints that have some additional conditional logic in them. And we definitely want either type of constraint to be easy to modify, with quality assurance, of course.

>
> The GUI, like an XML doc or a nested data structure, is a single and
> simplistic view of things. Real things can support multiple views, from
> various angles, which each have utility for different parts of the
business.
> But even in apps I've written, I've provided GUIs that let them envision
the
> data in different ways (sometimes they wanted to see paint color variants
by
> model, sometimes they wanted to see models by color variant.) Letting one
> particular GUI govern my rules is putting the cart before the horse.

You are right that it is not the way that the data is presented that is a constraint. You should be able to put different GUI views with the same constraints.

> > It does
> > seem like you are in the majority, but I just don't see what is gained
by
> > coding these rules twice in different languages -- sounds like busy work
> > that leads to complex-to-maintain software and is likely to be out of
> synch
> > with itself, with app programmers prone to change only the application
> > software and not the dbms constraints when they can do so.
>
> I agree, code them in an RDBMS and then apply simple templates to generate
> the UIs. We're in agreement.

I'll go for that. I don't have a reason to "gen" a lot of intermediate steps -- as someone once said (I'll have to track it down) "the code is the spec" so taking that code and gen'ing byte-code for whatever virtual machine you are running the dbms & UI constraint handling within ... [This is a dance we could do all day, of course, but bottom line is that we agree on the theory and envision different implementation approaches, I think]

I better do some "real work" for a while, so I'm leaving many juicy responses unanswered for now.
Cheers! --dawn Received on Wed Mar 03 2004 - 20:40:25 CET