Dirty data (was: 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.

Two change-cases:
1. constraint addition (data considered valid

    before is considered invalid after the change). 2. constraint removal (data considered invalid

    before is considered valid after it).

There is no risk in having a client out of sync due to a constraint addition. Out of sync after the removal of constraints is different: The client will reject perfectly valid data as long as it is out of sync after the removal of constraints from the database.

So: first upgrade the database.

> To be totally safe it would
> have to check with the central constraint repository before everything
> it does that could be affected, which would be a massive overhead.
>
> It could just check occasionally and hope that no relevant changes have
> been made in the meantime, but this doesn't seem totally satisfactory.
>
> 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.
>
> It does sound like a good idea to have clients share the database
> constraints but the devil is in the details.

Should all constraints be available at the client at any time? Received on Fri Jun 24 2005 - 10:32:40 CEST