Re: Newbie question

Kenneth Downs wrote:
> The source of the constraints is outside of both the db and the client, it
> is an outside source (in our case, a data file describing the database).
> The program the builds them into the DB is actually the *authority* for
> them as well, it enforces constraint changes during an upgrade. An upgrade
> is therefore defined as that process where the schema is changed (including
> constraints) and a new copy of the schema (including constraints) is given
> to the client.

OK I see. So in effect you have a meta-constraint that says: constraints may only be changed by a certain mechanism. Do you have something to prevent a sufficiently-privileged user from amending a constraint interactively, bypassing your upgrade mechanism?

It also presupposes you have control over the code for all the clients as well as a DBMS, which may not be true in the general case. Not to denigrate this method in other cases though.

I guess once you have "decoupled" clients and servers there's no real answer to this problem.

Also, what if you have a constraint that, for example, says the sum of some columns must be less than a certain value. And the client only has privileges to read one of the columns? Now you're forced to make a server trip and deal with the error in some meaningful way ("Error: the sum of your entry and two other numbers that you aren't allowed to know about should be less that 42")

Even for a foreign key constraint, the client will have to either query the "lookup" table first to check a corresponding entry exists, or else just try it and deal with the error if it fails. And in the first case, the lookup table may change between checking it and updating the main table. Unless it's in a transaction I suppose. In fact, aren't these two methods actually functionally equivalent? An INSERT that potentially fails is the same as a SELECT conditionally followed by an INSERT based on the result of the SELECT.

Paul. Received on Fri Jun 24 2005 - 16:04:38 CEST