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.
>
>No sorry, we do not borrow the data model. We simply try to support the
>class model that is present.

Well, if you knew what a data model is, you would know better than to write that.

>> Just try to teach an end-user to write Java code in their
>> interactive query tool! LOL
>
>We are working on a graphical user interface to query stored objects
 without
>the need for a query language.

Uh huh. Let me know when your end-users can answer questions like: "What is average salary and average commision paid to the most profitable salesperson in each state by region?" without writing Java when no Java function or property calculates profits per salesperson.

>> >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 I just posted, you can't write any programs in "relational".

You can't write programs with automobiles either. What's your point?

>Or could you
>a write a newsreader in "relational"?

Why would I want to? A DBMS manages data, as the name implies. Apparently, not only have you confused logical issues with physical issues, you don't even know the difference between data management and application development.

>Objects are there and used, that's a
>fact.

So? What's your point? A relational database with proper support for domains handles object classes and object instances beautifully. Are you suggesting that a network model OODBMS handles them better?

>The Java JDK is there and the classes are being used, that's a fact.

Agan, what's your point? That because someone writes applications in Java they should make certain that their data is not portable to any other system or programming language? Is the goal job security?

>We try to store them as they come.

Okay. Store them however you want. The relational model imposes no restrictions on storage.

>All the relational equivalents that you posted are
>- unnecessary extra concepts to learn

Not true.

>- unnecessary extra code

Not true.

>- bad for performance

Not true.

I am still having trouble discerning. Is the untruth intentional or just the result of ignorance?

>> >Every concept, additional or renamed:
>> >- 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!
>
>I am sorry but I don't understand what you mean with "algorithmic
>replacement".

It's simple enough as the name implies: replace one algorithm with another. For instance, replace a bubble-sort with a quick-sort. Or replace an order-n-cubed algorithm with an order-n algorithm.

In their famous compiler book (the Dragon Book), Aho et al. mention it as one of the most effective optimizations and the one least likely for compilers to actually achieve. SQL databases the world over achieve this kind of optimization on a daily basis.

Does your product support algorithmic replacement?

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