Jim,

>There is no product on the market that meets Codd's rules completely. Some meet more of them than others and xBase is somewhere at the bottom of the list on this point.

As far as I know SQL is not number 1 on this list too.

>>Though it's record oriented, we could skip this part and work set-oriented: this is also possible.
>
>Codd's whole point is that a relational product will not have any way to access the data other than the relational way. If there is another way then the product is not relational.

In this part I disagree. I've recently had a discussion if C++ was a pure object orient language. By definition a language is a pure OO when it does not have ways to violate the OO rules. C++ certainly has functionality to violate the OO rules, but does this make the language less OO ? I think not.

To me this argument is not that important. BTW if you read John Petersen messages, you'll discover that SQL-server also have record oriented operations. Does it make the product less Relational. IMO not.

>>We don't have to use record pointers, nor the commands which affect the current record, We could also use SQL commands.

>No, you don't.

Can you give me an example in which case I could not use a command which doesn't use a record oriented approach ?

>>So much for your generated primary keys :), yes it's true, but if you look at my concept, it isn't hard to automate the process and let the computer determine the structured hierarchy by specifying a limited SQL query (no group by and having clauses), though it capabilities might reach further. Maybe this wish could also being described as a FILTERED SQL resultset which is editable, and the indexes are available (both implicitly and explicitly). This FILTERED SQL resultset also must be available when joins are used.
>
>Generated primary keys have nothing to do with what I am saying. The use of a generated PK has no effect of the relationalness of a system other than if the system requires that I generate the key value then it is less relational. If i specify that this field is the primary key and give it a unique value for me, then it is relational.

My argument was based on that generated Pk are not a part of the logical design.

>>But we can use the relational approach, can we ?
>
>Codd's point in his definition, again, is that there is no other way. The relational approach is the only way to access the data.

See above.

>>To my knowledge SQL was invented by IBM (though i don't know if E.F. codd did help with this implementation). If he would have much to say about the implementation, SQL would not be as worse as it is today... Or Codd and DATE have a huge difference in opinion up here, which i think is highly unlikely.

>Relational database theory and SQL were both invented by E. F. Codd while he was working for IBM in the 70's.

Have you any docs to back this up ? I've got trouble to believe this. From what I know is that Codd invented the relational language, which is in fact less restrictive than SQL. SQL is derived from that language.

>I've read Chris Date and he often disagrees with his mentor (Codd).

Yep, he does.


Jim,

You're the only one here I think are able to inderstand what i'm trying to tell regarding the relational model. Please check http://www.utexas.edu/cc/dbms/utinfo/relmod/relmod3.html and look at the eight relational operators. With a little study you'll see that (except for the union, wich in fact has to be solved another way) those operations can be done within the wish i've submitted.

SQL SELECT operations are based on these same operators, but some of them are harder to implement.

Walter,