Re: Multiple specification of constraints

From: Eric Kaun <ekaun_at_yahoo.com>
Date: Mon, 08 Mar 2004 13:52:44 GMT
Message-ID: <MU_2c.32783$KK1.24205_at_newssvr16.news.prodigy.com>


"ben brugman" <ben_at_niethier.nl> wrote in message news:c2f7r0$4f$1_at_reader11.wxs.nl...
> >
> > Again, you're saying they allow manual access, but not programmatic?
Then
> > that data can hardly be considered a constraint in the automated sense.
A
> > manually-enforced constraint is no constraint, at least for computer
> > systems.
>
> You should think more outside of your box, no it is not a constraint for
> computer systems, but it still is a constraint.

I fully agree, but we still have to do the job of reducing external predicates to internal ones. That's analysis, a prerequisite for design.

> > > ben brugman
> >
> > Meaning the UI had the entire data set of members and their departments,
> and
> > "filtered" the set based on the selected department? If so, it's just
> > another example where a relational language on the client side (too much
> to
> > ask from most languages, much less the incoherent JavaScript) would have
> > made this trivial.
>
> No it is not, a selection on the name of the member could be made, adding
> the
> the departmentname to the member name now the members of a department
> can be selected. (Still done by the RDBMS).
>
> But the point was that this could be implemented without going through a
> application version cycle. The names were altered, the users were
instructed
> how
> they could use this feature, and they could use it few ours after
signaling
> that this
> was a users wish (or weak requirement).

I'm still very confused about the example. What did you have, what changed, and how did you make the change easily?

  • Eric
Received on Mon Mar 08 2004 - 14:52:44 CET

Original text of this message