Path: news.f.de.plusline.net!news-fra1.dfn.de!news-lei1.dfn.de!newsfeed.freenet.de!newspeer1.nwr.nac.net!newspeer.monmouth.com!newscon02.news.prodigy.net!prodigy.net!newsdst01.news.prodigy.net!prodigy.com!postmaster.news.prodigy.com!newssvr12.news.prodigy.net.POSTED!88885bfe!not-for-mail From: "Brian Selzer" Newsgroups: comp.databases.theory References: <45cd3acd$0$331$e4fe514c@news.xs4all.nl> <4620ae20$0$330$e4fe514c@news.xs4all.nl> <%qgVh.89055$6m4.56691@pd7urf1no> <4626a912$0$326$e4fe514c@news.xs4all.nl> <4627a88e$0$337$e4fe514c@news.xs4all.nl> <383Wh.100591$DE1.26701@pd7urf2no> Subject: Re: cdt glossary 0.1.1 [Transaction] Lines: 113 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.3790.2663 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 Message-ID: NNTP-Posting-Host: 68.73.73.118 X-Complaints-To: abuse@prodigy.net X-Trace: newssvr12.news.prodigy.net 1177077683 ST000 68.73.73.118 (Fri, 20 Apr 2007 10:01:23 EDT) NNTP-Posting-Date: Fri, 20 Apr 2007 10:01:23 EDT Organization: SBC http://yahoo.sbc.com X-UserInfo1: SCSYQNONWZRYBP@ZKROD]_\@VR]^@B@MCPWZKB]MPXH@ETUCCNSKQFCY@TXDX_WHSVB]ZEJLSNY\^J[CUVSA_QLFC^RQHUPH[P[NRWCCMLSNPOD_ESALHUK@TDFUZHBLJ\XGKL^NXA\EVHSP[D_C^B_^JCX^W]CHBAX]POG@SSAZQ\LE[DCNMUPG_VSC@VJM Date: Fri, 20 Apr 2007 14:01:23 GMT Xref: news.f.de.plusline.net comp.databases.theory:43432 "Bob Badour" wrote in message news:Us3Wh.26319$PV3.269358@ursa-nb00s0.nbnet.nb.ca... > paul c wrote: > >> Brian Selzer wrote: >> >>> "paul c" wrote in message >>> news:x6SVh.98742$DE1.19705@pd7urf2no... >>> >>>> mAsterdam wrote: >>>> >>>>> paul c wrote: >>> >>> [snip] >>> >>>> I wasn't suggesting it did. As far as I know, "order of work" is not a >>>> relational issue, nor is a transaction a relational concept any more >>>> than invoices are. Wondering why they aren't part of RT is like asking >>>> why the RM isn't based on a state machine. >>> >>> So what would you call something that transforms one database state into >>> another? In 1970, Codd called them "state-changing transactions." >>> ... >> >> Codd subscribed to the idea of a data sub-language. I think whenever he >> used terms such as "states" and "transactions", he was talking about a >> programming environment, not the RM. >> >> ... >> >>> I think that if a transaction contains more than one operation, then the >>> order in which each operation is evaluated is critical. 2 + 3 * 5 = 17, >>> not 25. >>> >>> After the following transaction, >>> >>> UPDATE r SET x = x + 5 WHERE k = 22, >>> UPDATE r SET x = x * 4 WHERE k = 22 >>> ... >> >> If all I wanted to do was to add 5 to x and then multiply by 4, I would >> expect my programming environment to give a single statement to the dbms, >> not two. >> >>> Is the result (x + 5) * 4 or (x * 4) + 5? Or is it x * 4, which is what >>> D&D's multiple assignment would produce? >>> ... > > Brian misses a very important point: D&D provide the WITH keyword. If one > wanted (x + 5) * 4, one could give a name to the (x + 5) expression > (assuming one did not know how to nest algebraic expressions in the first > place.) > > Thus, with the D&D approach, one can explicitly state whether it should be > (x + 5) * 4 or x * 4. Selzer clues out on the loss of the ability to > express x * 4 when depending on implicit information. > > >> I'm not in favour of encouraging the complexity that multiple assignment >> requires a programmer to be aware of. (I'm not even in favour of >> assignment to mutable variables. I realize most programmers are used to >> them and expect them to be supported, but I don't care.) >> >>> Do you limit a transaction so that only one transformation can occur per >>> relation? Per tuple? Per attribute value? >>> ... > > I prefer the D&D approach that doesn't require transactions at all. > Arbitrarily complex updates are single statements. > So why is BEGIN TRANSACTION and COMMIT specified as statements in Tutorial D? Obviously, D&D think they're important, or they wouldn't have been included. > >> Any concept of a database that has two different values at the same time >> is beyond me. > > Look! It's a bird! It's a plane! It's a figment of somebody's imagination! > > >>> Should all constraints be checked after each operation? Only some? Or >>> should they all be deferred until the end? I mention this because the >>> result of one operation may leave the database in an inconsistent state, >>> making any subsequent operations suspect. >>> ... >> >> Any dbms that allows a programmer to introduce an inconsistency should be >> recalled. >> >>> If it were possible to convert a group of statements into a single >>> operation, then there would be no need for order, there would only be >>> one transformation per relation, per tuple and per attribute value, and >>> constraints would only need to be checked once. Alas, this capability >>> is not available in any commercial system that I know of, and even D >>> doesn't doesn't support it. >>> ... > > Selzer is too stupid to realize that D does support it and supports it > correctly by requiring explicitness. > Wrong again! I suggest you revisit chapter 5 of TTM. > >> So what? (Most of IT is mistaken. People usually prefer to re-invent >> old wheels.) > > Indeed.