Re: Multiple specification of constraints

"Tony" <andrewst_at_onetel.net.uk> wrote in message news:c0e3f26e.0403010301.48d3c24c_at_posting.google.com...
> "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.

Although the interface with the user and the interface with data storage (part of the job of a DBMS) are different interfaces with different purposes, that does not mean that the run-time environment, constraint specification, and constraint logic MUST be different.

> 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

Or you could partition the software application services in this way:

a -- interface to user and/or "batch" (e.g. web services)
b -- constraint/validation services
c -- CRUD services

whereboth a and c are clients of the b services.

This means decoupling the CRUD services from the constraint services, while still ensuring that data that gets stored has been through the constraint/validation services. This possibly puts additional power in the hands of the application developers to botch up the database in a big way, but it is not as if that isn't the case anyway. It also tends to put the data architecture roles together in the application development process, rather than having one role, such as a dba, do data modeling for data storage and another, such as a an application software engineer, do the data modeling throughout the rest of the application (for the data in the interface with the UI and the web services, for example).

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

Nothing guarantees accurate data but if we take a wholistic approach to data integrity where we want to give the best shot we can at capturing accurate, meaningful, retrievable, validated, properly interpreted, etc data (not just what is currently in the DBMS constraint specs) we will give it a good shot. Good data management crosses the entirety of a software application, not just the "backend".

> 3) UI constraints only (your favoured option, Dawn?):

By no means -- I am not suggesting that we ditch the idea of applying database validation against constraint specifications AT ALL! I simply don't think we (as an industry) are taking a solid constraint/validation approach that makes for both data integrity and software development & maintenance efficiency & effectiveness.

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

An application developer could technically bypass the data integrity engine and employ the crud services in a test environment, with my scenario. However, the production environment could be established so that the s/w developer does not have the rights for that type of access -- the only access to the production CRUD services would be by way of the data integrity engine. This is not locked down in the same way as it is in a traditional DBMS and there are times when "traditional" DBMS lock down would be worthwhile but there is more than one way to accomplish our goals. Decoupling, while still interfacing, CRUD services from data integrity services gives some advantages:

1. maintainability, one place to make integrity changes; local & global typing specified using the same tools
2. cost of development; potentially faster and better quality with fewer "people interfaces" (and if you have not seen any example of a poor interface between DBAs and software developers, ...!)
3. cost of ownership, stems from combination of 1 & 2
4. data accuracy, by taking a wholistic approach to data quality, it shows in the resulting software

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

GUARANTEES?? If the software application has "Date of Birth" as a "screen prompt" for an attribute that is treated as "Date of Skull Fracture" (my creativity isn't up right now, but you get the idea), then you test the type of the data all you want and your data is definitely corrupted!

<snip>
I have to reboot (ah, Windows!) so I'll send what I have even though I know I didn't respond to the entire post. Cheers! --dawn Received on Mon Mar 01 2004 - 23:53:32 CET