Re: Unknown SQL

>> >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.
>
>Most object languages are very similar. You have classes, simple datatypes,
>arrays and inheritance. Lower level API classes that would typically be
>persisted like collections are also similar.
>
>The database API would be exactly the same.

Go back and read my original email on this topic for an abbreviated list of the ways that different OODBMSs differ in subtle and confounding ways.

>If you really need mixed language development (Do you do mix ORACLE- and
>Sybase-SQL-development ?) you would use class translators.

Yes, actually, I do mix database brands. I write commercial software and not every customer agrees on the correct database brand to support. Once they've made an investment in DBAs etc, they don't like to change just to suit a vendor.

>> >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... ?
>
>There simply is no (zero, nothing, rien, kein) administration work or
>maintenance work necessary to persist objects. The database engine analyzes
>classes automatically.

Are you for real? Of course there will be tons of administration work. How does the DBMS handle the fact that the Employee Object used by HR has subtle differences from the Employee Object used by Payroll and that Hiring an employee means different things to these different departments? How does it handle the fact that what it means to these departments this year is subtly different from what it meant last year and what it will mean next year?

I have already seen it pointed out to you several times that thirty years ago companies went down the path of basing their databases on specific applications and it did not work out. Database management must support use of the data for all applications.

>There is no need for normalization work, creating and maintaining tables,
>thinking about keys, no strings within code, no mismatch between
 inheritance
>hierarchies and tables.

Huh? Of course there is -- either you are ignorant of basic facts or you are ignoring them intentionally to try to make some kind of unsupportable case. Someone still has to design the data model. Unfortunately, the eventuality of the belief you currently espouse is that someone totally ignorant of what little science we can bring to bear on the problem will do the design incorrectly.

>The more complex your object model is, the higher the performance advantage
>on inserts and navigation will be.

Performance (physical) is completely orthogonal to data model (logical). As I mentioned in an earlier message, no reason exists why a relational database cannot have equivalent performance characteristics to an OO database.

>> 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.
>
>Yes of course I do.

Then when are you going to say anything at all that demonstrates such understanding?

>You don't seem to get the fact, that object databases have to care about
>OIDs at all. They won't even need to see the value 10.

If I store the value 10 in a database, the DBMS better damned well see the value 10. If I want to move that data out to a spread sheet and back into a different DBMS, they better all see the value 10 or else the data is corrupt.

>Why care about internal linkage, if it does not provide any needed
information?

Why have OID's at all? They provide no information whatsoever beyond the values stored in the database. You are confusing physical (internal linkage and pointers) with logical (uniquely identifying attributes). OID's, collections, arrays etc. expose the internal linkage to users, whereas RDBMS's do not expose the internal pointers and linkages at all.

>> >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?
>
>???
>Why care about the value 10?

Because RDBMSs locate information by uniquely identifying VALUES, and not by any kind of implementation-dependent pointer like every single OODBMS does!

>> How will any of the above address the fact that OIDs,
>> ie pointers, are necessarily implementation specific.
>
>The implementation specific work is done by the database vendor. It will be
>transparent to the user of the object database.

Since you don't seem to have a clue what we were talking about when you joined in, we were discussing how much easier it is to move data among heterogeneous RDBMS brands than it is to move data among heterogeneous OODBMS brands. Someone suggested that theory somehow made the difference, and I pointed out that the difference is much more basic and concrete than theory.

The fact that RDBMSs present data to the user explicitly as values (and as nothing else) is unrelated to first order predicate logic or to set theory. However, the fact implies profound advantages over any data model that presents data to the user as anything else. As OID's or as containment relationships, for instance.

Since the situation under discussion implies that the implementation specific work is done by two or more different database vendors, and since the OODBMS exposes those implementation differences to the user through OID's and other means, the differences will be anything but transparent to the user when they attempt to change brands.

Since you have already stated that the design will flow directly from the application based on the performance needs of a single application, the differences among different OODBMS vendors' implementation choices will drive a need for completely different application designs.

An application that relies on a specific type of pointer swizzling and caching can break under a different DBMS implementation.

If the DBMS vendor supports a limited number of programming languages (just C++ or C++ and java, for instance) the customer who expands through acquisition and inherits a few million lines of mission-critical COBOL and Fortran code will have one hell of a time doing the integration. Even if they assume ownership of a website written using an unsupported language, ASP or Perl for instance, they will have one hell of a time. Even a major smalltalk application will stop them in their tracks.

If you honestly believe that any OODBMS can transparently support C++, Java, VB and Perl (not to mention COBOL and Fortran) and can do so through several revisions to the applications without any kind of administration or maintenance and without any kind of data normalization or intentional design, I've got a bridge in lower Manhattan you might be interested in purchasing.... Received on Sun Jul 22 2001 - 01:27:16 CEST