Re: Multiple specification of constraints

>
> 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.

> > 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).

Bringing a new version to the user takes building it, retesting the complete application,
making a install for it and distributing it to the user. This takes time and money.

I agree with your arguments that technically it is not a beauty, but here the
economical arguments prevail. (Making a solution, which works, is cheap and satisfies the customer).

Just protesting against a solution our user allready has accepted (and paid for),
just shows that this theory group, builds a lot theory which is not geared towards
the real world. Yes theoretically your solutions are best. But best if often the
enemy of good enough. (And in the given example more expensive in money and sure with less usersatisfaction).

ben brugman.
>
> - Eric
>
>
Received on Sun Mar 07 2004 - 14:28:20 CET