Re: does a table always need a PK?

"Heikki Tuuri" <Heikki.Tuuri_at_innodb.com> wrote in message news:big0dj$3m9$1_at_phys-news1.kolumbus.fi...
> Bob,
>
> "Bob Badour" <bbadour_at_golden.net> kirjoitti viestissä
> news:BLL2b.951$Xb2.85420125_at_mantis.golden.net...
> > "Heikki Tuuri" <Heikki.Tuuri_at_innodb.com> wrote in message
> > news:9AE2b.79$4X.9_at_read3.inet.fi...
> > > Bob,
> > >
> > > "Bob Badour" <bbadour_at_golden.net> kirjoitti viestissä
> > > news:OYy2b.694$FE.81687684_at_mantis.golden.net...
> > > > "Heikki Tuuri" <Heikki.Tuuri_at_innodb.com> wrote in message
> > > ...
> > > > > if I can recall, the 1970 paper is not formulated as mathematical
> > axioms
> > > > > either. Or is it? Do you remember?
> > > >
> > > > rtfm: http://www.acm.org/classics/nov95/
> > >
> > > it is not. I did not find mathematical axioms there. Have you studied
> > > mathematics?
> >
> > I have studied mathematics enough to reconize that the "term relation
> [used]
> > in its accepted mathematical sense" is sufficiently axiomatized for most
> > mathematicians. A dbms is a formal logic system, and the axioms of that
> > system are actually the data in the database.
>
> for example, there are no NULLs in a mathematical relation.

That's arguable and depends entirely on what you think a NULL is. A set can contain anything.

> Codd should
> explain in detail how they are modeled in the relation (the mathematical
> structure). Did he?

See RM V2.
http://search.barnesandnoble.com/booksearch/isbnInquiry.asp?isbn=0201141922& itm=1

> > > For example, where in the 1970 paper is the following rule formalized?
> > >
> > > http://www.cis.ohio-state.edu/~sgomori/570/coddsrules.html:
> > >
> > > "
> > > 9. Logical Data Independence
> > > Application programs and terminal activities remain logically
unimpaired
> > > when information preserving changes of any kind that theoretically
> permit
> > > unimpairment are made to the base tables.
> > > "
> >
> > Once again, you ignore the formal system to complain that a rule of
thumb
> is
> > not formal. That's quite stupid, don't you think?
> >
> > As it happens, the above rule of thumb goes much deeper than axioms. One
> can
> > construct just about any formal system. For the formal system to be
> useful,
> > one must use a principled design for the formal system. To design a
formal
> > system useful for data management, one must consider the principles of
> good
> > data management in the design of the formal system.
> >
> > The above rule of thumb is actually a guiding principle for identifying
> the
> > principles of good data management. It encompasses such principles as
the
> > separation of concerns and the value of abstraction, which overlap
> somewhat
> > with the principles of good software development.
> >
> > Some will argue that mathematics does not have to be useful for anything
> but
> > mathematics, and I would agree. However, mathematicians use principles
> like
> > closure when devising their formal systems. If one compares two
arbitrary
> > formal systems, one can generally identify principles distinguishing the
> > systems. In fact, to a large measure this is what mathematicians do.
>
> Now you are approaching my view. Codd's 12 rules are heuristic thoughts
> which can be used to guide us to build formal systems.

Codd's 12 rules are vendor commissioned rules of thumb chosen in some respects to show the paying vendor in a good light relative to its competitors.

> They are not exact
> principles.

Excuse me? What exactly are exact principles? Do you realise how absurdly ridiculous you sound?

> ...
> > > > > "* FirstSQL/J Object/Relational DBMS "
> > > > >
> > > > > By the way, FirstSQL probably is not Codd-12-relational? Why do
you
> > > claim
> > > > it
> > > > > to be an 'object/relational' database then? Is it 'Lee
> > > > > Fesperman -relational'?
> > > >
> > > > It was me who pointed out SQL is not particularly relational--not
Lee.
> > > > FirstSQL, of course, suffers some of the same problems all SQL
dbmses
> > > > suffer. Unlike MySQL, I would count FirstSQL a dbms or at least a
> > > > significant subset of such a system.
> > >
> > > Lee's claims are grossly contradictory.
> >
> > Your claims are grossly contradictory, but Lee's are quite consistent.
>
> Now you are saying grossly contradictory things. Lee claims that 'the
> relational model' is not vague.

He is right and consistent. The relational model is not vague. See the 1970 paper.

> He claims his database is 'relational'.

He doesn't sell a database so he doesn't make any claims about "his database". He sells a dbms, and his claims regarding his dbms are well-supported. I suggest you check out the white papers etc. on his website at http://www.firstsql.com/ His product has greater relational fidelity than most SQL dbms products including your own. That makes his claims to sell an rdbms less specious than the specious claims of any other SQL dbms vendor.

Your own claims are particularly specious in that you do not sell a dbms--let alone an RDBMS.

> Since Lee believes Codd's 12 rules describe a 'relational' database,

Does he? I suspect Lee might have a more nuanced belief system than you attribute to him. Perhaps, you and I could agree to let him speak for himself.

> > When other SQL vendors stop making specious claims about being
relational,
> I
> > am sure Lee will stop too.
>
> Is this not intellectual dishonesty?

No, not necessarily. Perhaps, Lee will indulge us and allow us to judge his competence, intellectual honesty and integrity by answering the following questions. Heikki, you can indulge us by doing the same.

Lee, are you game? Heikki?

Is your product a dbms? If so, what are the features necessary to make it a dbms? If not, what additional components are required to make it a dbms?

Does SQL provide perfect relational fidelity?

Do any implemented or proposed languages provide greater relational fidelity than SQL?

If not relational fidelity, does SQL have any advantage over these languages? If so, what?

Are you aware of any sound theory purporting to deal with the problem of missing information?

Has anyone ever proposed a flawless solution to the problem of missing information?

Does the mathematical identity "SUM(A)+SUM(B)=SUM(A+B)" demonstrate a flaw or limitation of SQL's NULL?

If so, does 4VL overcome the specific flaw or limitation demonstrated?

Does 4VL overcome any flaws of 3VL? If so, can you briefly name or describe any?

Does 3VL overcome any flaws of 4VL? If so, can you briefly name or describe any?

Do Codd's 12 rules completely specify the relational model?

Briefly, in your opinion, what is the exact nature of Codd's list of 12 rules?

Is the list a useful tool for comparing dbms products?

Are all of the 12 rules equally important for such comparisons?

Are you aware of any products that can claim greater adherence to any of the rules than your product? Feel free to elaborate or to explain how your product's features compensate in some other way.

Overall, do any other SQL dbms products provide greater relational fidelity than your product?

Why do think your product provides greater relational fidelity than other SQL products?

From the answers to the above questions, one should be able to judge the competence, honesty and integrity of an SQL dbms vendor. Received on Tue Aug 26 2003 - 19:15:34 CEST