Re: Concurrency in an RDB
Date: Fri, 22 Dec 2006 18:12:54 GMT
Message-ID: <GeVih.36272$cz.535129_at_ursa-nb00s0.nbnet.nb.ca>
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.
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. Received on Fri Dec 22 2006 - 19:12:54 CET