Re: Newbie question about db normalization theory: redundant keys OK?

From: David BL <davidbl_at_iinet.net.au>
Date: Sun, 23 Dec 2007 17:02:59 -0800 (PST)
Message-ID: <129123ef-6eb3-4b91-9c64-8190d95273e3_at_e10g2000prf.googlegroups.com>


On Dec 24, 2:05 am, paul c <toledobythe..._at_ooyah.ac> wrote:
> Bob Badour wrote:
>
> ...
>
> > I am not sure Gray's stuff is incompatible with the information
> > principle. It seems orthogonal to me.
>
> I wouldn't argue with that but the distinction I'd prefer to think of as
> more useful is that concurrency theory viewed from the perspective of an
> rdbms operates at a physical level, often, maybe always, using artifacts
> such as "transaction id's, session id's" and so forth, that are hidden
> from apps.
>
> My complaint about conventional concurrency theory is that (as far as I
> know) it has never tried to express how a purely logical view that is
> visible to an application can achieve the same effects as a typical
> concurrency or lock manager component. I think one likely reason for
> this is that the concurrency theorists take physical persistence as
> their starting point. Given that, it's not surprising they would ignore
> the possibility of a suitable app language using a relational algebra to
> prototype the same effects.
>
> While implementing this might seem to deny one of Codd's goals, that of
> putting as much common logic in the rdbms rather than in app code, I
> also note that for the larger apps I've seen, there never failed to be
> some requirements compromise or other due to the concurrency strategy
> imposed by various dbms's.

Operational Transform (OT) tries to do exactly what you're alluding to. I have been investigating it for years now and can say that the mathematics is complex and very interesting. The basic idea is to think of changes to data structures as operations that can be generated and executed by different processes independently (and concurrently) on the same state without any locking, and the operations can be transformed as required to achieve the same logical effect when they are post-applied in different orders by the processes. This holds the promise of allowing for replicated databases which support local edits without being exposed to network latency or outages, and for asynchronous merging of changes in a similar fashion to CVS. Unfortunately, and not surprisingly there is a limited extent to which OT can preserve the original logical intention of the operations due to conflicts.

I would be hesitant to talk about any alternatives to Gray's approach with Badour. He considers it sacrilegious. I was plonked after only a brief discussion when I first posted to cdt. Received on Mon Dec 24 2007 - 02:02:59 CET

Original text of this message