Re: Newbie question

Paul wrote:

> David Cressey wrote:

>> There is value in avoiding round trips to the server.
>> 
>> With regard to keeping the client and the database in synch with regard
>> to
>> data constraints  (database constraints?),
>> there is another alternative.  Allow both the client and the database to
>> inherit the constraints from a common source.

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.

>
> It could just check occasionally and hope that no relevant changes have
> been made in the meantime, but this doesn't seem totally satisfactory.

Following on the above, the client does not have to check because of course it using the copy of the constraints it was given at the last upgrade, which copy is always refreshed at the next upgrade.

It is very important to provide the constraints in the form that is natural to the client language. In our implementation of this idea we have used PHP as the web logic layer, and so the constraint data is written out as huge associative arrays. There is one program file per table,

>
> The other option is that changes to the constraints are pushed to the
> clients in a kind of replication scheme, which could be made
> transaction-safe. In effect the clients become mini-DBMSs partially
> replicating from the central DBMS.

This is close to what we do, except I would stress that an agent that is neither the db nor the client is in control of the process. It reads the biz rules data file, builds the db, and generates a data file for the client that the client can read and deal with easily. The client never queries the db for constraint or structure info.

The spec for our data file is here:

http://www.secdat.com/dev/androspec.html

>
> It does sound like a good idea to have clients share the database
> constraints but the devil is in the details.
>

I believe we have exorcised that devil :) The clincher was in that idea of giving the client the complete specification in the form that makes sense, instead of trying to make the client act like a db server.

By contrast, if you look at the way things like .Net do it, it seems that "the devil hath invited seven of his friends" to come live in that haunted house. They attempt to recreate a db server in the client, instead of asking the more Aristotelian question, "what are the characteristics of a virtuous client that knows about databases?"

-- 
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth_at_(Sec)ure(Dat)a(.com)