Re: Multiple specification of constraints

"Jerome H. Gitomer" <jgitomer_at_erols.com> wrote in message news:40427498$0$3093$61fed72c_at_news.rcn.com...
> Dawn M. Wolthuis wrote:
> {SNIP}
> >
> > If I'm writing Java swing code, for example, or pick your favorite
> > environment, and I need to display a set of mutually exclusive options
(such
> > as true/false) or a short or long list from which the user selects one
or
> > more options, or a calendar from which to select a date, ... then the
data
> > constraints (such as the type of element, a range or set of valid
values,
> > max or min length, etc) need to be available for my java-written GUI (or
C,
> > or C++ or VB or ...).
>
> Why? If the data you are working with has already been
> validated and satisfies the constraints you should not have to
> revalidate it. Practical experience has shown that the best
> place for the constraints is in the database where they will
> appear once and only once.

I am in full agreement that we don't want to validate twice if we don't have to. But if we are tossing up a question to a user, or deciding whether to use a radio button or combo boxes or a text field entry or a calendar for date entry then where are we getting the validation from? Do we read the metadata from the database in order to put the proper information and format to the UI? If so, then won't we validate again when we do CRUD routines? If we are reading the typing and constraint specs from the database prior to doing any CRUD routines (e.g. in order to give the user an interface to add or lookup data) then the engine we are using to interpret those specs is different than the database engine, right? So, even if we can figure out a way not to duplicate entry of the typing and other constraints, we have to, effectively, write new logic for the UI since the DBMS is not operational at that time.

I would be thrilled to find out that I'm missing something here, but it seems to me that it is absolutely bottom-line required to have a large portion of the constraint information present when presenting an interface to the user (or to the web service for that matter, although I don't mean to muddy the waters any further with that point). That means that the specifications of the constraints, the interpretation of the constraints, and the run-time environment in which to test out the constraints should be part of the UI environment, while today it looks to me like both .NET and J2EE developers REWRITE IT so there are (at least) two sets of data typing and other constraint information.

Furthermore, if we are certain the data can only come into the database via a particular (set of ) service(s) and we know that service necessarily operates the constraint logic in this or a prior step, then there is no need (except that inner sanctum thing for extraordinary applications) for reapplying the constraint logic to the data, right?

>
> However, now they are buried in the dbms so
> > developers tend to write them again at the front-end of the process,
> > duplicating both specs and logic for applying such specs in a different
> > language. Bad plan, methinks.
>
> No, bad systems design and/or lousy management. If every
> programmer writes their own version of the constraints in every
> program incompatibilities and strange bugs can be guaranteed.

No doubt. I agree with you on that.
>
> An example from my own experience (my only excuse is that
> application was written BC -- Before Codd) I was managing a
> project operating on US Dept of Labor data collected in face to
> face interviews. There were 8 report programs in the
> application. Seven of them has consistent values for the number
> of male and female interviewees, the 8th had different values.
>
> It only took 80 some progammer hours to isolate the problem. In
> seven of the progams the number of males were counted and the
> difference between the population and the number of males was
> assumed to be female. In the 8th progam the number of females
> was counted and the difference between the population and the
> number of females was assumed to be male. An examination of the
> data collection forms revealed that the interviewers had not
> specified the sex of the interviewee in some cases, hence the
> discrepancies.
> >
> {SNIP}
> >
> >
> > Today if you have a constraint with multiple specifications and you want
to
> > change it, you must find all places it needs to change (GUI, database,
data
> > extraction tools, reporting tools?) and then find enough developers to
cover
> > all required skills and only then can it be changed.
>
> And that is the reason why your constraints should be part of
> the database and not appear elsewhere in your system.

That would be fine if the database specifications, logic, and run-time environment were present in the UI. But as far as I can see, it typcally is not. Cheers! --dawn Received on Mon Mar 01 2004 - 00:37:47 CET