Re: Concurrency in an RDB

Bob Badour wrote:
> Marshall wrote:
>
> > On Dec 21, 3:08 pm, "David" <davi..._at_iinet.net.au> wrote:
> >
> >>Marshall wrote:
> >>
> >>>So he wrote a couple of apps. Woo hoo. And he's told us, in
> >>>the most excruciatingly high level, handwavy manner possible,
> >>>that they have this and that awesome property.
> >>
> >>Your sarcasm doesn't do you credit.
> >
> > Mmmm, "sarcasm" isn't quite right. "Woo hoo" was dismissive
> > but not particularly harsh.
>
> Okay, so it wasn't harsh sarcasm.
>
>
> Nor was any irony present.
>
> I disagree. On their face, the words "Woo hoo" express excitement, and
> you used them to express the opposite. Likewise "awesome".
>
>
> Without
> > at least one and preferably both qualities, it doesn't qualify
> > as sarcasm. On the other hand "dismissive" is too soft.
> > Le bon mot eludes me at the moment.
>
> Sarcasm works for me. I fail to see how it discredits you, however.
> Although, I can see how it will make David dislike you.
>
> [snip]
>
>
> >>As I've said before, the details about how OT works is not the subject
> >>of this thread. It is more about the repercussions of using OT in a
> >>DBMS.
> >
> > Just looking at the basics, I don't see how it would be possible to
> > use this for a DBMS. DBMSs are useful because of the properties
> > they guarantee, and it strikes me that the most fundamental such
> > property is durability: when I commit, I can count on it sticking.
> > Also very important: integrity enforcement. It appears you want
> > to restrict what integrity constraints can be enforced centrally.
> > That's not very appealing.
> >
> > For some restricted set of applications where durability
> > most-of-the-time is good enough, and integrity constraints
> > are few, it might be useful. Collaborative editing seems
> > like a good fit. Not source code control or anything that
> > handles money, though.
>
> I agree. From the examples given, like a shared whiteboard, I think
> David discounts the integrity enforcement foisted off onto multiple
> pairs of human eyes. Integrity has to work even in the absence of human
> eyes.

I've said many times in this thread that complex integrity constraints can and should be enforced indirectly through separate validation/verification queries. Here are some examples where that approach is already used in today's applications

1. Source code compilation
2. Software unit testing
3. VLSI chip layout constraints
4. Digital circuit verification
5. Finite element modelling verification
6. Geometric model verification

Surely you agree these sorts of constraints shouldn't be enforced on every update to the DB?

I have the impression (please correct me if I'm wrong) that your assumption that a DB should always be in a valid state is coloured by the (relational) problems that you have expertise in.

Cheers,
David Received on Sat Dec 23 2006 - 01:52:00 CET