Re: Unknown SQL

From: Bob Badour <bbadour_at_golden.net>
Date: Sat, 21 Jul 2001 23:26:43 GMT
Message-ID: <_O_Q6.617$042.166865961_at_radon.golden.net>


Carl Rosenberger wrote in message <9djb3e$9kd$03$1_at_news.t-online.com>...
>Bob Badour wrote:
>> Network model databases, however, represent data with pointers and other
>> physical constructs that vary greatly among different vendors. Further
>> issues such as shallow copies vs. deep copies, pointer swizzling,
 implicit
>> back-pointers etc. vary as well. Every different implementation of
 network
>> model database changes the meaning of the data implied by physical
>> constructs by introducing often subtle differences in interpretation.
>
>Bob,
>
>all of the above is very true.
>
>With the evolution of object databases things will change.

Either you are extremely naive or you are blind to basic facts.

>Ideally object databases do not need specialized implementations.

Object languages expose physical implementation details to programmers. Subsequently, when object languages differ, databases based on them must differ as well. Your 'ideal' was long ago defined out of existence.

>They can simply use all the constructs that the respective programming
language offers.

So, every OO database is specific to a single programming language. Kinda supports my points about portability -- n'est pas?

>This is where we are headed:
>- no need to derive from a specific class

Who cares?

>- no need to implement a specific interface

So?

>- support for all language constructs like two-way pointers, collections,
>hashmaps

And your point would be... ?

>If object databases do not introduce unneeded own constructs, switching
>between vendors becomes very easy: You simply need no maintenance work at
>all. Load all objects out of one database and store it to the other.

Provided you deal with a single programming language as implied by your 'respective programming language' statement above, and provided all OO databases for that language use the same OID format internally. You don't seem to get the fact that the value 10 remains constant no matter how one represents it. Philip gets it.

>Of course there are areas where standardization work will be necessary:
>1.) Persistency callback functions
>2.) Queries
>3.) Locking and isolation level behaviour

How will any of the above address the fact that the value 10 remains the same among all value based systems including all relational databases? How will any of the above address the fact that OIDs, ie pointers, are necessarily implementation specific.

The rest of your message was too irrelevant for comment.

Regards,
Bob
Received on Sun Jul 22 2001 - 01:26:43 CEST

Original text of this message