Re: does a table always need a PK?
Date: Sun, 31 Aug 2003 01:18:32 -0400
Message-ID: <4Ig4b.206$Mo2.24859765_at_mantis.golden.net>
"Lee Fesperman" <firstsql_at_ix.netcom.com> wrote in message
news:3F510C49.2A6E_at_ix.netcom.com...
> Bob Badour wrote:
> >
> > 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?
>
> My responses for FirstSQL/J are below.
>
> > 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?
>
> FirstSQL/J is a DBMS. Its management features include:
>
> + Structure and datatypes (domains)
> + Security and Authentication
> + Data Integrity
> + Concurrency control
> + Optimization and Performance
> + Physical Management
> + High Availability
> + Manipulation of data at the logical level only
Those are succinct and eloquent descriptions of the key features. Certainly, a dbms requires all of those features, and the list appears comprehensive on initial examination. That's a more competent job than I could do in the time you have had to work on it, which suggests you have a much deeper comprehension of the issues than I have.
If another reader (Jan are you reading?) notices any serious omissions, please speak up.
> > Does SQL provide perfect relational fidelity?
>
> No. Using SQL92 as an example, here are some of its failings:
>
> + Insufficient manipulative power, for example: no transitive closure.
> + Missing capabilities, for example: does not require candidate keys and
primary keys,
> no domain support, no updateability of joins.
> + A number of flaws, for example: several important flaws in its 3VL
implementation (the
> "EXISTS Bug" is one example).
That's an honest and detailed answer showing sound comprehension of the issues.
> > Do any implemented or proposed languages provide greater relational
fidelity
> > than SQL?
>
> Two that I am familiar with are Alpha and Quel. I am not familiar with
Dataphor.
Again, I would say that's an honest answer that clearly expresses some of the limits of your knowledge.
> > If not relational fidelity, does SQL have any advantage over these
> > languages? If so, what?
>
> It doesn't have technical advantages, but it is standardized and widely
supported
> (though inconsistently).
I would add that it is commercially accepted and widely understood among available resources. Admittedly, I never asked for an exhaustive list of advantages, and restraint in advertising one's advantages shows modesty.
> > Are you aware of any sound theory purporting to deal with the problem of
> > missing information?
>
> No.
>
> > Has anyone ever proposed a flawless solution to the problem of missing
> > information?
>
> No.
>
> > Does the mathematical identity "SUM(A)+SUM(B)=SUM(A+B)" demonstrate a
flaw
> > or limitation of SQL's NULL?
>
> No, if you ignore the empty set issue.
I am surprised by this answer, because I know we have discussed it before. Given the following table, T:
A B = = 1 2 3 NULL
NULL 4 What are the results of the following queries?
select SUM(A) from T; select SUM(B) from T; select SUM(A+B) from T;
Am I missing something?
> > If so, does 4VL overcome the specific flaw or limitation demonstrated?
>
> No.
>
> > Does 4VL overcome any flaws of 3VL? If so, can you briefly name or
describe
> > any?
>
> No. It does extend expressiveness at the price of greater complexity.
An excellent answer.
> > Does 3VL overcome any flaws of 4VL? If so, can you briefly name or
describe
> > any?
>
> Not definitively. We have produced a 'sound' implementation of 3VL based
on our own
> extensive research. We have not researched 4VL implementation, nor are we
aware of any
> usable research.
>
> > Do Codd's 12 rules completely specify the relational model?
>
> No.
>
> > Briefly, in your opinion, what is the exact nature of Codd's list of 12
> > rules?
>
> They are guidelines for DBMS users to determine the relational compliance
of their
> systems.
>
> > Is the list a useful tool for comparing dbms products?
>
> Yes, it can be. However, most existing SQL DBMSs score very close
together.
>
> > Are all of the 12 rules equally important for such comparisons?
>
> I consider them fairly equal in importance but highly interdependent. The
exception is
> the Information Rule (sometimes called Rule #0); it is primary.
>
> > 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.
>
> I am not familiar with Dataphor, otherwise I believe FirstSQL/J exceeds
other DBMSs by a
> small margin. On the other hand, FirstSQL/J extends the margin with
features only
> implied by the 12 rules -- even optimization and fewer flaws (like 3VL
processing).
An excellent answer.
> > Overall, do any other SQL dbms products provide greater relational
fidelity
> > than your product?
>
> No.
>
> > Why do think your product provides greater relational fidelity than
other
> > SQL products?
>
> + Even optimization
> + 2 types of nulls
> + Reduced flaws and limitations
> + Domain support
> + Recursive queries
> + Candidate key support
Another excellent answer.
> > From the answers to the above questions, one should be able to judge the
> > competence, honesty and integrity of an SQL dbms vendor.
Thank you for your indulgence, Lee. I look forward to a reply to my question regarding SUM(A+B) above. Regardless, I know what my conclusions are regarding your competence, honesty and integrity. Received on Sun Aug 31 2003 - 07:18:32 CEST