Re: Unknown SQL

>> >arrays, n-dimensional arrays, classes without public constructors, inner
>> >classes, all JDK Collection classes, simple types, interfaces ...
>>
>> So many concepts, so much complexity. Beyond making things more difficult
>> for users, what good is it for?
>
>All of these concepts are part of the Java programming language.

All of these concepts are part of your data model. The fact that you borrowed your data model from Java in no way makes your data model any simpler. Just try to teach an end-user to write Java code in their interactive query tool! LOL

>If you see
>a concept that could be replaced by a better one, please send an RFE to
Sun.

Sure. Replace Array with Relation. Replace Bag with Relation. Replace Set with Relation. Replace Collection with Relation. Class and Domain are equivalent so it matters little which name one uses. Replace Iterators with set-level operators. Um, I could go on for quite some time, but I am getting thirsty.

>> >As far as I know, our product is the only object database with this
>> >approach. Our point of view:
>> >The less additional concepts a database adds,
>>
>> You have a funny way of delivering that. Relational replaces all of the
>> above concepts and many more concepts with three: relation, tuple,
 domain.
>>
>> These are not additional concepts -- simply different names for existing
>> ones.
>
>Now what?
>Relational *replaces* concepts or uses *different* names?

Both. Set, Bag, Array and Collection differ only in physical structure. Relation replaces all of them with a single logical construct. The relational model calls user defined data types Domains. Java calls them Classes. The concept is the same -- only the names are changed.

>Why?
>Every concept, additional or renamed:
>- costs time and money to learn

If one understands the concept of user defined data type, it takes but a brief second to understand domain. They are the same thing with different names.

I agree that each additional concept, however, requires additional learning time, which is why Relation saves so much time and effort over Array, Set, Bag, Object and Collection.

>- adds causes for error

I agree with this too. If you mix up your Array and your Bag, you could be in deep, deep trouble, which is why it is easier for users to learn only Relation. If someone mixes up their Relation with their Relation, little harm will ensue.

>- introduces standardization problems between vendors

It introduces much more than standardization problems. Aho et al. mention that one of the most effective optimization techniques is algorithmic replacement. How many object oriented languages or OODBMSs do you know capable of algorithmic replacement? Every SQL product on the market performs this extremely potent optimization technique. Even small-footprint products like Lee's!

Regards,
Bob Received on Sun Jul 22 2001 - 01:28:12 CEST