Re: Multiple specification of constraints

"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