Re: Multiple specification of constraints

"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message news:<c1tt55$k12$1_at_news.netins.net>...
> 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.

Given that the DBMS and the UI are 2 different things, which of course they are, then it isn't feasible to have one single implementation of the constraints that serves both the database and the UI. The nearest you can currently get is to generate the UI constraints from the DBMS constraints. So you currently have 4 choices:

1) No constraints at all
2) DBMS constraints only
3) UI constraints only
4) Both DBMS and UI constraints

1. No constraints at all: clearly undesirable (I hope we all agree on at least this!)
2. DBMS constraints only: this GUARANTEES that the data will never get corrupted, even though the UI allows the user to enter bad data. It gives the user a poor experience, but at least the data can't be corrupted for sure.
3. UI constraints only (your favoured option, Dawn?): this guarantees the user a good experience, and guantees that the data will never be corrupted IF IT IS ENTERED VIA THIS UI. It does not and CANNOT guarantee that the data will not be corrupted by other applications, or by bypassing the UI altogether. You have to legislate that this UI is THE ONLY way to access the database.
4. Both DBMS and UI constraints: this obviously GUARANTEES that the database will never get corrupted, and ALSO gives the end user a good experience, which is nice. Of course, there is a cost in duplicating the constraints: at worst, re-writing them in another language; at best, pressing the "re-generate UI constraints" button in some tool. But the 2 sets of constraints serve different purposes: the DBMS constraints are for data integrity, and the UI constraints are for enhancing user experience/productivity. The UI constraints are NOT in any way responsible for data integrity.

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

If you can and want to restrict your universe in that way, then of course. Maybe for some trivial databases that may suffice in practice. You are treating the database as being privately owned by your single application, and must ensure that that is so. That is how programs were written over 30 years ago: with datafiles that can only be written and read by the application that "knows how to do it". If that works for you, good luck! But do you really think that your Java/Jini/J2EE/[insert other buzzwords beginning with J here] application is that last word in applications? Or is it more likely that in 5-10 years time it will be considered obsolete and rewritten in a new "paradigm" that involves a different set of acronyms? On the other hand, the DATA never goes out of fashion, that will still be wanted and integrity will still be as important. Protect that data integrity in the DBMS, and you are free to change the UI at will, in the sure knowledge that the worst you can do is annoy some users; you will not be able to corrupt the data. Received on Mon Mar 01 2004 - 05:01:58 CST