Re: The Practical Benefits of the Relational Model

"Bob Badour" <bbadour_at_golden.net> wrote in message news:<FLox9.148$hg4.48773260_at_radon.golden.net>...
> "Paul G. Brown" <paul_geoffrey_brown_at_yahoo.com> wrote in message
> news:57da7b56.0211032027.7e218417_at_posting.google.com...
> > I dunno. I guess I don't see a logical difference here.
>
> One may have multiple 'multiple assignment' statements in a transaction. The
> dbms can perform the steps necessary to update the database for a 'multiple
> assignment' statement in any order that yields the correct result.

  As opposed to designing a transaction manager which ensures that, regardless   of the order in which the operations are performed:

     i. All of the changes happen or none of them do.     ii. The database is left in a consistent state at the end of all of

        the changes.
   iii. Independent sets of changes are managed in such a way that no set

        of changes is influenced by another.     iv. Once made, the change is permenent.  

> > What can be done with 'multiple assignment operators' that cannot be
> > done with explicit transaction boundaries? (Or should I just get with
> the
> > program a bit more?)
>
> Non-deferred integrity enforcement for all integrity constraints.

    Maybe it's just the systems I've used but non-deferred constraint checking    is the default. Defering constraint checking is *really* hard to do in some    cases. I guess re-ordering the operations would allow you to give the    impression of deferred constraints without implementing some of the    arbitrary magic-theorem-proving-hat-dances you would have to do otherwise.

> Global
> optimization over updates to multiple relations.

     True enough. But this is an implementation difference, not a logical     difference, no?

> Semantic optimization.

      Oooh. All kinds of badness lurks here.

> Those seem fairly obvious to me. I am sure plenty of other benefits accrue
> that I haven't considered in the past few seconds since I started to
> consider your question.

     Benefits, maybe. But each with its own costs, I'd expect.

     But my question was with regards to *logical* differences. For example,     does it make the merging of transactions any easier? (I don't think so,     and it might make it harder). What about more elaborate serialization     models? Or does it provide a model for operations on streaming data?  

> Why do you assume that transaction boundaries relate solely to integrity
> enforcement and not simply to concurrency?

    Oh dear me, I'm not. And it's not just concurrency either (there are    *way* too many Pauls on this thread).

   Transaction for me is a term with a very specific meaning: 'transactional'   changes to a database variable (if that's the jargon we're using: might just   as well say transactional changes to any 'signal') are always ACIDic --   Atomic, Consistent, Isolated and Durable. Each othese terms also has a   precise meaning (see my four point blather above).

    If you want an interesting question, how do you model 'transactional   changes' over 'streaming' data (what is durability? what is serialization?).   Compensation messages?

    KR

           Pb Received on Mon Nov 04 2002 - 22:53:26 CET