Re: does a table always need a PK?

"Heikki Tuuri" <Heikki.Tuuri_at_innodb.com> wrote in message news:<C1j4b.55$TR6.11_at_read3.inet.fi>...

> now we are coming to mathematical logic, which is my subject. Powerful
> formal systems are NOT decidable. That is the famous result of Kurt Gödel
> from about year 1930. For example, there are sentences of arithmetic which
> are not provable from Peano's axioms, and their negation is neither.

   Ahh! Using decidability in that sense is no fair on this forum!

   Of course the math is incomplete. But for the purposes of determining   whether a view is updateable or not, it suffices to divide views   into two classes: those which can be shown to be safely updatable and   those which cannot. In most DBMS products the 'formal model' consists   of a limited physical algebra (insufficient even to develop integer   arithmetic). Consequently there are views whch are (obviously) updateable   in theory sense but the DBMS lacks the smarts to figure it out all by   itself.

    "Better" implementations of an RDBMS (used here in both the Bob & Lee   sense and the pragmatic sense) permit more views to be updated.

     Folks have critized the Twelve Rules as criteria for judging   implementations on other grounds. The rules say *nothing* about how the   product chooses its physical access path, for example. A rule which said   that all logically equivalent queries have identical physical access   paths would have gone a long way towards cementing 'what not how' and   defining what 'declarative' meant. But for some reason Codd   overlooked this critical element of system functionality.  

> It still is not clear to me what you mean by 'the Relational Model'.

   Well, it isn't clear to me either. Which I think is a good thing. Critical   thinking is less applicable to what you know than it is to what you don't.   But in this context propositions about the 'Relational Model' can be   distinguished from propositions about 'R'DBMS products. That's all I'm   saying.

> That is why I am talking about
> Codd-1970-relational and Codd-12-relational. Codd 12 probably has no formal
> definition, at least no one in this discussion has been able to point out
> where the formal definition was published.

  [ snip ]

     The reason no one has been able to point to formal definitions for the   12 rules is because there are none. But that doesn't make the twelve   rules any less useful for criticially evaluating DBMS implementations.

     Put it another way: as much as folk would love to be able to say things   like "I don't care about implementation details: we're talking about the   logical model here.", it simply doesn't cut much cheese. In the end you've   got to have a working system or no one (outside a small circle of friends)   cares because what you have is impractical.

    Recall the lambda calculus? A powerful and complete system for reasoning   about computation that gave rise to a number of computer programming   languages most notably LISP. But look where that model is now. And why?   Because implementing it was a bear. And for all the huffing and puffing   you hear implementing a working semi-Relational DBMS is *really* hard.

    What you heard from proponents of sets over bags are all of the good   things sets give you, but none of the bad things, chiefly the need to   ensure that each edge in the physical query plan consists of unique   rows. This means a) figuring out when the edge's set properties are   guaranteed by the schema semantics (keys, unique columns) or the   physical database (columns in a unique index appear in the tuple), and   then when there is no guarantee b) imposing a blocking physical operation   to guarantee the uniqueness.

    Set algebras were tried. They slowed the systems down. Whether or not this   makes them impractical is an open question but to be honest about it, it   isn't clear that the much touted advantages of set algebras outweigh their   disadvantages. Theory is inherently practical.

    KR

            Pb Received on Sun Aug 31 2003 - 21:28:13 CEST