Re: Arbitrary Constraints

From: Tony Andrews <>
Date: 27 Oct 2004 08:31:23 -0700
Message-ID: <>

Dawn M. Wolthuis wrote:
> Then if there were a way to ensure that only validated data made its
way to
> the database services (CRUD), there would be no reason to double up
> validation, right?

Wrong. Suppose you are creating a new employee record, and your UI validated that the department code you used was valid, i.e. existed in the department table and had a status of "open for new employees" or whatever. But in the few seconds (or minutes, if the user is tardy) between your UI doing the validation and sending the new data to the database, someone else deletes the department, or sets its status to "closed for new employees" or whatever. Congratulations, you have now corrupted the database.

You could counter by saying that you will ensure this does not happen, by writing your own code in the UI to re-validate and to lock the department record against changes by other users. So now your UI is becoming a DBMS! And no one can (safely) modify the database other than through that UI. Also, your UI will probably not act as a DBMS as efficiently or securely as a "proper" DBMS which has matured for many years. And you will be writing a lot of code that you don't need to.

> > The important consideration that is so often overlooked by people
> > a "developer" mindset and not a "database" mindset is that
> > come and go, come and go, but the data is there "forever".
> You can probably guess that I'm one of "those" people, but I do
> that the data are there for multiple applications, which each
application is
> only doing it's thing. That's the reason I suggest that the CRUD
> reject any requests that do not come through proper channels.

OK, but again you have just moved the responsibility for integrity "up a level" - and into more than once place, if there is more than one "proper channel". Why isn't it better to have a DBMS that can work securely even with data from "improper channels"?

> There are systems that need this type of control, but I think our
> could move forward faster if we get those constraint specs out of the
> proprietary database language and into services that can be used by
> aspect of any application that needs to have the constraint logic,
> the crud services.

I have no objection to the database constraints being accessible to the application in a non-proprietary manner, for it to use as it sees fit. Just as long as they are still there in the DBMS! Received on Wed Oct 27 2004 - 17:31:23 CEST

Original text of this message