Re: does a table always need a PK?

From: Lee Fesperman <firstsql_at_ix.netcom.com>
Date: Sat, 30 Aug 2003 20:45:22 GMT
Message-ID: <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

> 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).

> 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.

> 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).

> 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.

> 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.

> 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).

> 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

> From the answers to the above questions, one should be able to judge the
> competence, honesty and integrity of an SQL dbms vendor.

-- 
Lee Fesperman, FirstSQL, Inc. (http://www.firstsql.com)
==============================================================
* The Ultimate DBMS is here!
* FirstSQL/J Object/Relational DBMS  (http://www.firstsql.com)
Received on Sat Aug 30 2003 - 22:45:22 CEST

Original text of this message