Re: Unknown SQL

Bob Badour wrote:
> >> 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.

After reading all your postings in this thread I can not find a list of the differences.

I do agree that there is no practiced standard for object databases. We were not discussing this theme though. We were talking about support for different programming languages from one single object database with the same API.

> >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.

Congratulations!
What syntax do you use for outer joins?
ANSI-standard or ORACLE-standard?

> >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?

The work to reflect changes is to be done in the programming code, am I right?

There are object databases that automatically handle schema changes. Still there is no maintenance work necessary to adjust the database schema. It will continously be analysed by the database engine.

If you think you need proxy objects to provide a different view at employee objects from HR and from Payroll, why not create the classes for them?

If you want versioning, fine.
Why not work with different versioned classes derived from a base employee class for the 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.

The fact that companies go up and down is not directly associated with the technical quality of the products. Just yesterday I have received some private information on the decline of O2, inspite of the fact that it was technically the best object database.

IT does change, and it changes quickly.

Object-oriented languages were not common 10 years ago. Today they are.

It is time for object databases.

> >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.

No. Someone designs the class model.
Storage is taken care of by the object database.

> >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).

O.K. if you think so.

Compare the following:

1.)
table Person
  int personPkey
  String name
  boolean isEmployee
  String employeeID
  boolean isManager
  String managedDepartment

2.)
table Person
  int personPkey
  String name

table Employee
  int employeePkey
  int personFkey
  String employeeID

table Manager
  int managerPkey
  int employeeFkey
  String managedDepartment

What is your favourite flavour?

1.)
SELECT * from Person
  WHERE isManager = true

2.)
SELECT * from Person, Employee, Manager
  WHERE personPkey = personFkey
  AND employeeFkey = employeePkey

Version 1. will result in a monster table, totally unhandy and very unperformant.

Version 2. will get you ugly unperfomant queries, ugly subselects and ugly outer joins. Would you like to provide a solution for "<all employees>, <and their possible managed department, if they are managers> WHERE <the name is 'Badour'> <but I don't want managers of the department 'flames'> ?

This, I am afraid, is the object-relational-mismatch.

Now where does performance come in?
In the choice of an adequate table model. There is no one-size-fits-all table model to map objects to relational databases.
They just don't match.

> As
> I mentioned in an earlier message, no reason exists why a relational
> database cannot have equivalent performance characteristics to an OO
> database.

One reason among others:
Primary keys for outer joins have to be generated, sent back to the insertion code and used by new INSERT statements. Object databases handle this internally, so they do it faster and transparent to application programmers code.

[Value 10 discussion skipped]
Object databases store the value 10 and deliver back the stored value 10. ...hopefully even for Excel spreadsheets... Where is the problem?

> >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.

Wrong.
OIDs are (hopefully) not exposed to users.

RDBMS expose primary keys and foreign keys, don't they? You even need to take care of them in your queries.

> >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!

Internals pointers are not visible to the user, so why do you care?

Do the users of relational databases bother about the memory handling the engine uses to allocate memory to evaluate queries?

> Since you don't seem to have a clue what we were talking about when you
> joined in

My newsreader and my memory tell me that I started this thread on the 25th of April. I have been reading all the postings, inspite of the unfriendly tone.

>, 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.

No doubt, this is true.

> 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.

The difference will indeed be awful, as soon as users are using proprietary APIs. However OIDs are not the problem, since they are handled transparently by most vendors. OID dependant code is bad habit, but possible, if vendors expose them.

> 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.

Not necessarily, depending on the API features used.

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

The dinosaur that uses pointer swizzling is dead.

> 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.

No doubt, if the object database has no support for the respective programming language, you are lost. Using object databases, you also take the risk that the specific language will be abandoned by the vendor. This has happened.

The situation among object databases is not as beautiful as it could be. This will change.

> 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....

No doubt, support for SQL is currently spread over more platforms than any object database standard. Give us some time to catch up.

Kind regards,
Carl

---
Carl Rosenberger
db4o - database for objects - http://www.db4o.com