Object-Oriented databases Reaerch

Sarah wrote:
 > I m doing a research survey on Querying Object-Oriented Databases. I
 > have come across 3 types of approaches.
 >
 > 1. Object-Oriented database queried by Object-Oriented Language
 > 2. Object-Oriented database queried by Relational Language
 > 3. Relational database queried by Object-Oriented Language
 >
 > For the survey i have to evaluate the different products of these
 > three kinds of approaches.Can anyone help me in identifying the
 > products for these approaches


Hi Sarah,

I am quite sure that your posting will start discussions about
terminologies. Is SQL relational? How does an object-oriented
query language look like?

Let me list some of the query approaches available:


S.O.D.A.
--------

I start with this one and I will write a little more detailed, since
this is our approach.

To use S.O.D.A. you construct a graph representation to represent the
objects that you are looking for, very much like query-by-example.
Every node of this graph is a constraint to the query - by class or
value. Navigation through the graph is possible from root to leaves by
using field names. You can add any complex object to every node as a
constraint. Every non-null field value will be added to the graph. The
evaluation mode of nodes can be modified individually. You can run the
values of a node of the graph against your own code during query
evaluation.

Here are two examples to document the above.

Simplest possible: Query-by-Example
-----------------------------------

// Assuming that you have a Person object created somewhere in code
// with some of the field values set by a form or whatever:

Person person;
person.setFirstName("Peter");
person.setLastName("Pan");

// Simply plug the object into a S.O.D.A. query:

Query q = database.query();
q.constrain(person);
ObjectSet objectSet = q.execute();



More features
-------------

// Let's start off with the person class

Query q = database.query();
q.constrain(Person.class);

// Navigating to a node and modifying the evaluation mode

q.descend("age").constrain(new Integer(30)).greater();

// setting up your own code to run in the the query

q.constrain(new Evaluation() {
public void evaluate(Candidate candidate) {
Person person = candidate.getObject();
boolean take = person.calculateSalary() > 40000;
candidate.include(take);
}
});

// and execute the above

ObjectSet objectSet = q.execute();


Clearly S.O.D.A. is object-oriented, as object-oriented can be.


JDOQL
-----
JDO is an attempt to set a standard for Java object persistence.
JDO comes with a querying approach named "JDOQL". JDOQL allows you to
write Java-like code as "filters" in string expressions. You can plug
in object values as parameters.
JDO was written for object databases *and* object-relational mappers
and it shows. The O-R mapper implementations create single SQL queries
from JDOQL queries so clearly the ability to create this mapping was a
constraint in the specification process. The fact that SQL support is
planned to be a feature for next-generation JDO shows that JDOQL is
not a success.

I wouldn't really call JDOQL "object-oriented", but it's an attempt.


SQL
---
This is the mainstream relational querying language and I need not say
more.

SQL is not object-oriented.

There are some dialects that support table inheritance which I think is
a good approach.

Some products support serializing objects to attributes and calling
attribute methods during queries. In my opinion the approach breaks
both the relational concept and the object-oriented concept. What if
the object in the table attribute needs to hold a reference to another
table or another attribute? It doesn't work.


OQL
---
OQL is an object extension to SQL, that was developed and maintainted by
the ODMG. The ODMG is no longer in existence. Most of the people that used
to be involved with the ODMG became part of the JDO specification process.
Sind the ODMG is dead, OQL is somewhat dead also.


Propietary object APIs (let's call them "POA")
-----------------------------------------------
Many object databases supply their own query mechanims. Most of them only
allow simple tasks, not really advanced. It's up to you, what you will let
the through as "queried by object-oriented languages".



Here are some suggestions for products that you could try as representatives
for the above:

( no guarantees on my list of querying support, please correct me if
I am wrong)


Object databases
----------------
db4o S.O.D.A.
FastObjects OQL, JDOQL
Versant VDS SQL, JDOQL, POA
Intersystems Caché SQL



Object Relational mappers
-------------------------
Hibernate POA
Apache OJB OQL, JDOQL
Solarmetric Kodo JDOQL


If you need a list of all object database products, you may want to use the
links on the following websites:

<a style='text-decoration: underline;' href="http://www.cetus-links.org/oo_db_systems_1.html" target="_blank">http://www.cetus-links.org/oo_db_systems_1.html</a>
<a style='text-decoration: underline;' href="http://www.odbms.org" target="_blank">http://www.odbms.org</a>


Kind regards,
Carl
--
Carl Rosenberger
db4o - database for objects - <a style='text-decoration: underline;' href="http://www.db4o.com" target="_blank">http://www.db4o.com</a><!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Object-Oriented databases Reaerch 

Carl Rosenberger wrote:
 >
 > Sarah wrote:
  > > I m doing a research survey on Querying Object-Oriented Databases. I
  > > have come across 3 types of approaches.
  > >
  > > 1. Object-Oriented database queried by Object-Oriented Language
  > > 2. Object-Oriented database queried by Relational Language
  > > 3. Relational database queried by Object-Oriented Language
  > >
 >
 > Let me list some of the query approaches available:
 >
 > S.O.D.A.
 > --------
 >
 > --- snipped ---
 >
 > Clearly S.O.D.A. is object-oriented, as object-oriented can be.

SODA is a primitive query facility. It is thoroughly procedural in nature. Effectively,
you expected to write the query plan yourself. With the procedural approach, you
describe 'how' to retrieve the desire results. With a declarative approach (like SQL),
you describe 'what' results are desired.

The possibilities for optimization are limited with procedural queries. On the other
hand, the opportunities for optimization are enormous with declarative queries.

 > JDOQL
 > -----
 > JDO is an attempt to set a standard for Java object persistence.
 > JDO comes with a querying approach named "JDOQL". JDOQL allows you to
 > write Java-like code as "filters" in string expressions. You can plug
 > in object values as parameters.
 > JDO was written for object databases *and* object-relational mappers
 > and it shows. The O-R mapper implementations create single SQL queries
 > from JDOQL queries so clearly the ability to create this mapping was a
 > constraint in the specification process. The fact that SQL support is
 > planned to be a feature for next-generation JDO shows that JDOQL is
 > not a success.
 >
 > I wouldn't really call JDOQL "object-oriented", but it's an attempt.

"Object-oriented query facilities" are doomed to failure. They use ancient technology,
from the '60s.

 > SQL
 > ---
 > This is the mainstream relational querying language and I need not say
 > more.
 >
 > SQL is not object-oriented.
 >
 > There are some dialects that support table inheritance which I think is
 > a good approach.
 >
 > Some products support serializing objects to attributes and calling
 > attribute methods during queries. In my opinion the approach breaks
 > both the relational concept and the object-oriented concept. What if
 > the object in the table attribute needs to hold a reference to another
 > table or another attribute? It doesn't work.

Don't misinform. A relational database only provides references between table rows and
only uses keys for those references. Any other type of reference would be unneccesary
complexity.

--
Lee Fesperman, FirstSQL, Inc. (http://www.firstsql.com)
==============================================================
* The Ultimate DBMS is here!
* FirstSQL/J Object/Relational DBMS (http://www.firstsql.com)<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Object-Oriented databases Reaerch 

siddiquisarah RemoveThis @hotmail.com (Sarah) wrote in message news:<3dee490.0403200324.255cdfee RemoveThis @posting.google.com>...

 > I m doing a research survey on Querying Object-Oriented Databases. I
 > have come across 3 types of approaches.
 >
 > 1. Object-Oriented database queried by Object-Oriented Language
 > 2. Object-Oriented database queried by Relational Language
 > 3. Relational database queried by Object-Oriented Language
 >
 > For the survey i have to evaluate the different products of these
 > three kinds of approaches.Can anyone help me in identifying the
 > products for these approaches

You should define first what Object-Oriented database means. There are
two very different kinds of Object Databases: relational and
pre-relational.

What about: Object Oriented Relational Database queried by
Object-Oriented Relational Language?

A few links that could interest you.

<a style='text-decoration: underline;' href="http://www.alphora.com" target="_blank">www.alphora.com</a>
<a style='text-decoration: underline;' href="http://www.firstsql.com" target="_blank">www.firstsql.com</a>

<a style='text-decoration: underline;' href="http://www.dbmsmag.com/int9410.html" target="_blank">www.dbmsmag.com/int9410.html</a>
<a style='text-decoration: underline;' href="http://www.dbdebunk.com" target="_blank">www.dbdebunk.com</a>



Regards
Alfredo<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Object-Oriented databases Reaerch 

"Bob Nemec" <bobn.TakeThisOut@rogers.com> wrote in message news:<405c4504$1@news.totallyobjects.com>...
 > Sounds like we're "1. Object-Oriented database queried by Object-Oriented
 > Language", but you have an interesting bias: a database has data that you
 > need to 'query' in order to get what you need. I think of an OO database
 > differently: a persistent object model that I 'navigate'.

This only apply to pre-relational OO databases like Object Network
databases and Object Hierarchical databases, but not to Object
Relational databases (relational databases in a short).

The Relational Model was intended to replace manual navigation, and to
provide physical path independence (among many other things). We can
change the paths without afecting the applications, and the optimizer
looks for the current best path at any moment in run-time. The
optimizer can be viewed as an automatic programmer who 'navigate' the
physical database freeing humans from such tedious job.


Regards
Alfredo<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Object-Oriented databases Reaerch 

Interesting. Which commercial product does this (object relationship
optimization) now?
Does it require that all relationship references be done by a query?
('select from all children where parent is self' vs. 'my children')
--
Bob Nemec
Northwater Objects

"Alfredo Novoa" <alfredo.TakeThisOut@ncs.es> wrote in message
news:e4330f45.0403220701.6bf9a886@posting.google.com...
 > "Bob Nemec" <bobn.TakeThisOut@rogers.com> wrote in message
news:<405c4504$1@news.totallyobjects.com>...
  > > Sounds like we're "1. Object-Oriented database queried by
Object-Oriented
  > > Language", but you have an interesting bias: a database has data that
you
  > > need to 'query' in order to get what you need. I think of an OO
database
  > > differently: a persistent object model that I 'navigate'.
 >
 > This only apply to pre-relational OO databases like Object Network
 > databases and Object Hierarchical databases, but not to Object
 > Relational databases (relational databases in a short).
 >
 > The Relational Model was intended to replace manual navigation, and to
 > provide physical path independence (among many other things). We can
 > change the paths without afecting the applications, and the optimizer
 > looks for the current best path at any moment in run-time. The
 > optimizer can be viewed as an automatic programmer who 'navigate' the
 > physical database freeing humans from such tedious job.
 >
 >
 > Regards
 > Alfredo<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Object-Oriented databases Reaerch 

"Carl Rosenberger" <carl.RemoveThis@db4o.com> wrote in message
news:c3hge2$9p0$06$1@news.t-online.com...
 > Hi Sarah,
 >
 > I am quite sure that your posting will start discussions about
 > terminologies. Is SQL relational?

Not really. It's perhaps artificially relational-scented, but far from the
real thing.

 > How does an object-oriented query language look like?

Difficult to say when the formal underpinnings of object-orientation are,
when understood (which is rare), also ignored. If you're interested, read
the writings of Luca Cardelli.

 > Let me list some of the query approaches available:

I'll also point out that "approaches" is a lousy substitute for something
solid. Apparently survival-of-the-fittest approaches to software are doomed
to replace actual rational thought.

 > S.O.D.A.
 > --------
 > I start with this one and I will write a little more detailed, since
 > this is our approach.
 >
 > To use S.O.D.A. you construct a graph representation to represent the
 > objects that you are looking for, very much like query-by-example.
 > Every node of this graph is a constraint to the query - by class or
 > value. Navigation through the graph is possible from root to leaves by
 > using field names.

In other words, this is completely different than query-by-example which,
despite its flaws, doesn't force you to specify navigational paths (which
are application-specific and prone to change, unlike the business's actual
data). Navigational paths is also where XQuery, and anything based on a
hierarchy / object graph, is doomed to fail. Navigational paths are often
done for convenience, represent redundancy which must be enforced tediously
through procedural code, and are a poor basis for queries, an operation that
should represent a theorem derived from facts.

 > You can add any complex object to every node as a
 > constraint. Every non-null field value will be added to the graph. The
 > evaluation mode of nodes can be modified individually.

Allowing you to save the computer tedious work by specifying everything
yourself in a nearly-procedural fashion.

 > You can run the
 > values of a node of the graph against your own code during query
 > evaluation.
 >
 > Here are two examples to document the above.
 >
 > Simplest possible: Query-by-Example
 > -----------------------------------
 > // Assuming that you have a Person object created somewhere in code
 > // with some of the field values set by a form or whatever:
 > Person person;
 > person.setFirstName("Peter");
 > person.setLastName("Pan");
 >
 > // Simply plug the object into a S.O.D.A. query:
 >
 > Query q = database.query();
 > q.constrain(person);
 > ObjectSet objectSet = q.execute();
 >
 >
 >
 > More features
 > -------------
 >
 > // Let's start off with the person class
 >
 > Query q = database.query();
 > q.constrain(Person.class);
 >
 > // Navigating to a node and modifying the evaluation mode
 >
 > q.descend("age").constrain(new Integer(30)).greater();
 >
 > // setting up your own code to run in the the query
 >
 > q.constrain(new Evaluation() {
 > public void evaluate(Candidate candidate) {
 > Person person = candidate.getObject();
 > boolean take = person.calculateSalary() > 40000;
 > candidate.include(take);
 > }
 > });
 >
 > // and execute the above
 >
 > ObjectSet objectSet = q.execute();
 >
 > Clearly S.O.D.A. is object-oriented, as object-oriented can be.

Which explains the awkwardness of the query, I suppose. 5 lines of code to
represent "where salary(person)>40000 and age(person)>30". Nice.

 > JDOQL
 > -----
 > JDO is an attempt to set a standard for Java object persistence.
 > JDO comes with a querying approach named "JDOQL". JDOQL allows you to
 > write Java-like code as "filters" in string expressions. You can plug
 > in object values as parameters.
 > JDO was written for object databases *and* object-relational mappers
 > and it shows. The O-R mapper implementations create single SQL queries
 > from JDOQL queries so clearly the ability to create this mapping was a
 > constraint in the specification process. The fact that SQL support is
 > planned to be a feature for next-generation JDO shows that JDOQL is
 > not a success.
 >
 > I wouldn't really call JDOQL "object-oriented", but it's an attempt.

Perhaps "object-oriented" wasn't its goal - after all, it's far from a given
that "object-oriented" equals "sound" and "well-understood".

 > SQL
 > ---
 > This is the mainstream relational querying language and I need not say
 > more.

Except perhaps that it's not relational?

 > SQL is not object-oriented.

Recent revisions allow definition of types, limited though it is - so yes,
there is object-orientation of a sort.

 > There are some dialects that support table inheritance which I think is
 > a good approach.

Unfortunately it's not...

 > Some products support serializing objects to attributes and calling
 > attribute methods during queries. In my opinion the approach breaks
 > both the relational concept and the object-oriented concept. What if
 > the object in the table attribute needs to hold a reference to another
 > table or another attribute? It doesn't work.

Agreed, so you shouldn't do it. Adhere to the relational model.

 > OQL
 > ---
 > OQL is an object extension to SQL, that was developed and maintainted by
 > the ODMG. The ODMG is no longer in existence. Most of the people that used
 > to be involved with the ODMG became part of the JDO specification process.
 > Sind the ODMG is dead, OQL is somewhat dead also.

One down, many more to go...

- erk<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Object-Oriented databases Reaerch 

"Bob Nemec" <bobn.RemoveThis@rogers.com> wrote in message news:<405f3911.RemoveThis@news.totallyobjects.com>...
 > Interesting. Which commercial product does this (object relationship
 > optimization) now?

All SQL DBMS products have access path optimization.

 > Does it require that all relationship references be done by a query?
 > ('select from all children where parent is self' vs. 'my children')

You can create a view called my_children if you want.

Regards
Alfredo<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Object-Oriented databases Reaerch 

"Alfredo Novoa" <alfredo.TakeThisOut@ncs.es> wrote in message
news:e4330f45.0403230615.461fcd4b@posting.google.com...
 > "Bob Nemec" <bobn.TakeThisOut@rogers.com> wrote in message
news:<405f3911.TakeThisOut@news.totallyobjects.com>...
  > > Interesting. Which commercial product does this (object relationship
  > > optimization) now?
 >
 > All SQL DBMS products have access path optimization.

Ah ... I re-read your previous post. When you said...

"This only apply to pre-relational OO databases like Object Network
databases and Object Hierarchical databases, but not to Object Relational
databases (relational databases in a short)"

.... I missed the 'relational databases in short' part. At first I though we
had some new "Object Relational database" implementations to talk about.

So this is nothing new: SQL DBMS products are good at optimizing access
paths and OODBs implement hard coded access paths in the application code.
The same trade off still applies: you can either make *every* link dynamic,
and have the SQL DBMS optimize the link as best as it can, or you can make
the primary navigations static (faster) and do the optimizations manually.

If your applications has many well understood small links for each business
action (like a complex financial application) the static link model works
better. If your application has many ad-hoc queries, the dynamic approach
works better. Pick your poison.
--
Bob Nemec
Northwater Objects<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Object-Oriented databases Reaerch 

Lee Fesperman wrote:
  > > Clearly S.O.D.A. is object-oriented, as object-oriented can be.
 >
 > SODA is a primitive query facility. It is thoroughly procedural in nature.

Your "The world is flat." statements are completely ridiculous.

S.O.D.A. allows to plug existing objects into queries, consequently
S.O.D.A. is object-oriented.


 > Effectively, you expected to write the query plan yourself.

Wrong.

It's up to the query processor to decide, which constraint to evaluate
first. It will do so, by checking indexes.


 > With the procedural approach, you
 > describe 'how' to retrieve the desire results. With a declarative approach (like SQL),
 > you describe 'what' results are desired.

S.O.D.A. supplies Query-By-Example.

There is no simpler way to describe "what" you want returned by a query
than to create an example object.


 > The possibilities for optimization are limited with procedural queries. On the other
 > hand, the opportunities for optimization are enormous with declarative queries.

I challenge you to race our database engines against eachother:
db4o against FirstSQL.

I suggest that you supply one query problem, I will do the same.
We both write two solutions and compare performance results.

I am looking forward to see how "opportunities for optimization" are
used by your product.


 > "Object-oriented query facilities" are doomed to failure. They use ancient
 > technology, from the '60s.

FUD.

Java is not ancient technology.
..NET is not ancient technology.

Both environments hold data in objects.

Programming is simpler, if objects can be stored directly.
It's faster.
Less lines of code are necessary.
Refactoring is less work.
Programs use less ressources.

I can easily prove the above.

Feel free to supply any Java program for FirstSQL.
I will show that I can write a more elegant solution with far less lines
of code and I will prove that it will execute faster.


  > > Some products support serializing objects to attributes and calling
  > > attribute methods during queries. In my opinion the approach breaks
  > > both the relational concept and the object-oriented concept. What if
  > > the object in the table attribute needs to hold a reference to another
  > > table or another attribute? It doesn't work.
 >
 > Don't misinform. A relational database only provides references between table rows and
 > only uses keys for those references. Any other type of reference would be unneccesary
 > complexity.

This is another "Grass is blue." statement.
Object-oriented applications work with networks of interrelated objects.
True object-oriented querying allows to retrieve any node of the network.
If you can't do that, there is no point in serializing part of the network.
You are merely using classes as struct definitions.


Kind regards,
Carl
--
Carl Rosenberger
db4o - database for objects - <a style='text-decoration: underline;' href="http://www.db4o.com" target="_blank">http://www.db4o.com</a><!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Object-Oriented databases Reaerch 

Eric Kaun wrote:
  > > S.O.D.A.
  > >
  > > To use S.O.D.A. you construct a graph representation to represent the
  > > objects that you are looking for, very much like query-by-example.
  > > Every node of this graph is a constraint to the query - by class or
  > > value. Navigation through the graph is possible from root to leaves by
  > > using field names.
 >
 > In other words, this is completely different than query-by-example

You either did not read my example or you did not understand it:

Query q = database.query();
q.constrain(person);
ObjectSet objectSet = q.execute();

This is query-by-example.


 > Navigational paths is also where XQuery, and anything based on a
 > hierarchy / object graph, is doomed to fail.

Why?

Tell me where the above does not get the job done.


 > Navigational paths are often
 > done for convenience, represent redundancy which must be enforced tediously
 > through procedural code, and are a poor basis for queries, an operation that
 > should represent a theorem derived from facts.

Define and explain "should". Why?


  > > Query q = database.query();
  > > q.constrain(Person.class);
  > >
  > > // Navigating to a node and modifying the evaluation mode
  > >
  > > q.descend("age").constrain(new Integer(30)).greater();
  > >
  > > // setting up your own code to run in the the query
  > >
  > > q.constrain(new Evaluation() {
  > > public void evaluate(Candidate candidate) {
  > > Person person = candidate.getObject();
  > > boolean take = person.calculateSalary() > 40000;
  > > candidate.include(take);
  > > }
  > > });
  > >
  > > // and execute the above
  > >
  > > ObjectSet objectSet = q.execute();
  > >
  > > Clearly S.O.D.A. is object-oriented, as object-oriented can be.
 >
 > Which explains the awkwardness of the query, I suppose. 5 lines of code to
 > represent "where salary(person)>40000 and age(person)>30". Nice.

Are you suggesting to encode business logic with stored procedures?

I don't think that you will reach the same level of productivity and
portability as with Java or .NET.


Your "where salary(person)>40000 and age(person)>30" SQL one-liner
looks a lot different, if you have to turn it into a runnable Java
example to return Person objects:

String sql = "SELECT * FROM PERSON WHERE salary(PERSON)>4000 AND age(PERSON)>30";
Statement statement = connection.createStatement();
ResultSet rs = s.executeQuery(sql);
while(rs.next()){
Person person = new Person();
person.firsName = rs.getString("firstName");
person.lastName = rs.getString("lastName");
person.id = rs.getInt("id");

// lots of
// more
// mapping
// code
// for
// each
// field
}


Furthermore the S.O.D.A. approach provides much better query performance
and it will use less ressources. It does not need a parser to parse the
SQL statement.


Kind regards,
Carl
--
Carl Rosenberger
db4o - database for objects - <a style='text-decoration: underline;' href="http://www.db4o.com" target="_blank">http://www.db4o.com</a><!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Object-Oriented databases Reaerch 

"Carl Rosenberger" <carl.RemoveThis@db4o.com> wrote:
 > Person person;
 > person.setFirstName("Peter");
 > person.setLastName("Pan");
 >
 > // Simply plug the object into a S.O.D.A. query:
 >
 > Query q = database.query();
 > q.constrain(person);
 > ObjectSet objectSet = q.execute();

Lee Fesperman <firstsql.RemoveThis@ix.netcom.com> wrote:

 > SODA is a primitive query facility. It is thoroughly procedural in nature.
 > Effectively,
 > you expected to write the query plan yourself.

I can't tell that from Carl's example.

I've not been following the SODA stuff closely but the code he wrote
looked pretty declarative to me, nothing procedural about how the query
was evaluated, following links or whatever.

Have I missed something previously discussed or is this prejudice
speaking?

Whilst we're on the topic of prejudices, I've been involved in
application development for most of the last 22 years, covering most
kinds of commercial app through to scientific databases.

I'm struggling to remember a database app which was NOT in some parts
navigational or in which the application code knew about hierarchical
relationships, within some subset of the database.

Maybe we're all using different definitions of the same terms here.

I call Procedural when I see a loop of application code filling a
listbox from a set of data.

I call it Declarative if the app:
a) defines a query
b) binds a listbox to the data set

Sometimes it is hard to see past the knee-jerk, vitriolica arguments on
this forum to judge if people are even talking about comparable issues.

"My strawman is more twisted than yours!"

--
Andy Dent BSc MACS AACM
OOFILE - Database, Reports, Graphs, GUI for c++ on Mac, Unix & Windows
PP2MFC - PowerPlant->MFC portability
<a style='text-decoration: underline;' href="http://www.oofile.com.au/" target="_blank">http://www.oofile.com.au/</a><!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Object-Oriented databases Reaerch 

"Carl Rosenberger" <carl DeleteThis @db4o.com> wrote in message news:<c3hge2$9p0$06$1@news.t-online.com>...
 > Sarah wrote:
  > > I m doing a research survey on Querying Object-Oriented Databases. I
  > > have come across 3 types of approaches.
  > >
  > > 1. Object-Oriented database queried by Object-Oriented Language
  > > 2. Object-Oriented database queried by Relational Language
  > > 3. Relational database queried by Object-Oriented Language
  > >
  > > For the survey i have to evaluate the different products of these
  > > three kinds of approaches.Can anyone help me in identifying the
  > > products for these approaches
 >
 >
 > Hi Sarah,
 >
 > I am quite sure that your posting will start discussions about
 > terminologies. Is SQL relational? How does an object-oriented
 > query language look like?
 >
 > Let me list some of the query approaches available:
 >
 >
 > S.O.D.A.
 > --------
 >
 > I start with this one and I will write a little more detailed, since
 > this is our approach.
 >
 > To use S.O.D.A. you construct a graph representation to represent the
 > objects that you are looking for, very much like query-by-example.
 > Every node of this graph is a constraint to the query - by class or
 > value. Navigation through the graph is possible from root to leaves by
 > using field names. You can add any complex object to every node as a
 > constraint. Every non-null field value will be added to the graph. The
 > evaluation mode of nodes can be modified individually. You can run the
 > values of a node of the graph against your own code during query
 > evaluation.
 >
 > Here are two examples to document the above.
 >
 > Simplest possible: Query-by-Example
 > -----------------------------------
 >
 > // Assuming that you have a Person object created somewhere in code
 > // with some of the field values set by a form or whatever:
 >
 > Person person;
 > person.setFirstName("Peter");
 > person.setLastName("Pan");
 >
 > // Simply plug the object into a S.O.D.A. query:
 >
 > Query q = database.query();
 > q.constrain(person);
 > ObjectSet objectSet = q.execute();
 >
 >
 >
 > More features
 > -------------
 >
 > // Let's start off with the person class
 >
 > Query q = database.query();
 > q.constrain(Person.class);
 >
 > // Navigating to a node and modifying the evaluation mode
 >
 > q.descend("age").constrain(new Integer(30)).greater();
 >
 > // setting up your own code to run in the the query
 >
 > q.constrain(new Evaluation() {
 > public void evaluate(Candidate candidate) {
 > Person person = candidate.getObject();
 > boolean take = person.calculateSalary() > 40000;
 > candidate.include(take);
 > }
 > });
 >
 > // and execute the above
 >
 > ObjectSet objectSet = q.execute();
 >
 >
 > Clearly S.O.D.A. is object-oriented, as object-oriented can be.
 >
 >
 > JDOQL
 > -----
 > JDO is an attempt to set a standard for Java object persistence.
 > JDO comes with a querying approach named "JDOQL". JDOQL allows you to
 > write Java-like code as "filters" in string expressions. You can plug
 > in object values as parameters.
 > JDO was written for object databases *and* object-relational mappers
 > and it shows. The O-R mapper implementations create single SQL queries
 > from JDOQL queries so clearly the ability to create this mapping was a
 > constraint in the specification process. The fact that SQL support is
 > planned to be a feature for next-generation JDO shows that JDOQL is
 > not a success.
 >
 > I wouldn't really call JDOQL "object-oriented", but it's an attempt.
 >
 >
 > SQL
 > ---
 > This is the mainstream relational querying language and I need not say
 > more.
 >
 > SQL is not object-oriented.
 >
 > There are some dialects that support table inheritance which I think is
 > a good approach.
 >
 > Some products support serializing objects to attributes and calling
 > attribute methods during queries. In my opinion the approach breaks
 > both the relational concept and the object-oriented concept. What if
 > the object in the table attribute needs to hold a reference to another
 > table or another attribute? It doesn't work.
 >
 >
 > OQL
 > ---
 > OQL is an object extension to SQL, that was developed and maintainted by
 > the ODMG. The ODMG is no longer in existence. Most of the people that used
 > to be involved with the ODMG became part of the JDO specification process.
 > Sind the ODMG is dead, OQL is somewhat dead also.
 >
 >
 > Propietary object APIs (let's call them "POA")
 > -----------------------------------------------
 > Many object databases supply their own query mechanims. Most of them only
 > allow simple tasks, not really advanced. It's up to you, what you will let
 > the through as "queried by object-oriented languages".
 >
 >
 >
 > Here are some suggestions for products that you could try as representatives
 > for the above:
 >
 > ( no guarantees on my list of querying support, please correct me if
 > I am wrong)
 >
 >
 > Object databases
 > ----------------
 > db4o S.O.D.A.
 > FastObjects OQL, JDOQL
 > Versant VDS SQL, JDOQL, POA
 > Intersystems Caché SQL
 >
 >
 >
 > Object Relational mappers
 > -------------------------
 > Hibernate POA
 > Apache OJB OQL, JDOQL
 > Solarmetric Kodo JDOQL
 >
 >
 > If you need a list of all object database products, you may want to use the
 > links on the following websites:
 >
<font color=purple> > <a style='text-decoration: underline;' href="http://www.cetus-links.org/oo_db_systems_1.html</font" target="_blank">http://www.cetus-links.org/oo_db_systems_1.html</font</a>>
<font color=purple> > <a style='text-decoration: underline;' href="http://www.odbms.org</font" target="_blank">http://www.odbms.org</font</a>>
 >
 >
 > Kind regards,
 > Carl

Hi Carl,
Thanks a lot for your views in so much detail. I have gone through
the links mentioned by you , but i have some confusions regarding that
the same language could be used for the object database as well as the
object relational mappers.
OQL is a querying language for the object-oriented databases used for
FastObjects . As i have gone through the examples of OQL it looks
syntactically very closer to the SQL, so in my views its a relational
mapper to the object-oriented databases. Please do correct me if i am
wrong!!.
OQL Example,
//Searching for customers by matching data members
//(OQL)
SELECT Customer from CustomerExtent as Customer
WHERE CustomerName="M*";

//Searching for customers that references an object
(Java embeded with OQL)

OQLQuery query= new OQLQuery();

query.create ("Select Customer " +
"FROM CustomerExtent AS Customer " +
"WHERE Customer.Address = $1";");

query.bind(Address);
Object result = query.execute();

You see that is pretty much closer to SQL but i don't know its
internal parsing e.t.c. So in my opinion its only an Object relational
mapper i.e. Relational layer over an object-oriented database.

But S.O.D.A looks an object-oriented querying language used for
querying object-oriented database.

Also i would like to have some more information about Relational
database queried by Object-Oriented Language i think this approach all
has to do with the persistency of objects if the objects are saved in
the form of the tables alongwith their relationships then the third
approach OO Language mapper over the Relational database will hold.
Can i get some more example about this approach.

Thanks,

Sarah<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Object-Oriented databases Reaerch 

Carl Rosenberger wrote:
 >
 > Lee Fesperman wrote:
   > > > Clearly S.O.D.A. is object-oriented, as object-oriented can be.
  > >
  > > SODA is a primitive query facility. It is thoroughly procedural in nature.
 >
 > Your "The world is flat." statements are completely ridiculous.

The irony is that you are espousing the *old* way of doing databases (pointer-based:
hierarchical/network data model) that was superseded by the relational model.

 > S.O.D.A. allows to plug existing objects into queries, consequently
 > S.O.D.A. is object-oriented.

Fine. Though object-oriented is so vague as to defy definition.

  > > Effectively, you expected to write the query plan yourself.
 >
 > Wrong.
 >
 > It's up to the query processor to decide, which constraint to evaluate
 > first. It will do so, by checking indexes.

That is just a restrict operation, with limited opportunities for optimization. You
didn't mention navigation.

  > > With the procedural approach, you
  > > describe 'how' to retrieve the desire results. With a declarative
  > > approach (like SQL), you describe 'what' results are desired.
 >
 > S.O.D.A. supplies Query-By-Example.
 >
 > There is no simpler way to describe "what" you want returned by a query
 > than to create an example object.

There is more to querying than just restrict.

At best, SODA is a query algebra and not a calculus, thus it is not declarative.

  > > "Object-oriented query facilities" are doomed to failure. They use ancient
  > > technology, from the '60s.
 >
 > FUD.
 >
 > Java is not ancient technology.
 > .NET is not ancient technology.
 >
 > Both environments hold data in objects.

Java is a programming language, not a database. .NET is ... not a database. You have
trouble understanding the distinction. I have tried to explain it to you before, so I
won't waste further bandwidth.

 > Programming is simpler, if objects can be stored directly.
 > It's faster.
 > Less lines of code are necessary.
 > Refactoring is less work.
 > Programs use less ressources.
 >
 > I can easily prove the above.

Sure, it's a lean, mean object persistence machine.

 > Feel free to supply any Java program for FirstSQL.
 > I will show that I can write a more elegant solution with far less lines
 > of code and I will prove that it will execute faster.

Right. You want to compare a full Object/Relational DBMS supporting major standards
(JDBC/ODBC, SQL, XA) against an object persistence store supporting a primitive,
proprietary query facility?

Since you said 'any' Java program, how about one issuing a single SQL command -- a
cascading update with a subquery using recursion and 3VL? Or, how about an EJB
utilitizing CMP that must run on all the major app servers (without code change)?

   > > > Some products support serializing objects to attributes and calling
   > > > attribute methods during queries. In my opinion the approach breaks
   > > > both the relational concept and the object-oriented concept. What if
   > > > the object in the table attribute needs to hold a reference to another
   > > > table or another attribute? It doesn't work.
  > >
  > > Don't misinform. A relational database only provides references
  > > between table rows and only uses keys for those references. Any
  > > other type of reference would be unneccesary complexity.
 >
 > This is another "Grass is blue." statement.
 > Object-oriented applications work with networks of interrelated objects.
 > True object-oriented querying allows to retrieve any node of the network.
 > If you can't do that, there is no point in serializing part of the network.
 > You are merely using classes as struct definitions.

Relational querying allows you to retrieve any object directly, without traversing a
network.

Serializing a part of the 'network' is an object persistence strategy, not a database.
Navigation is complex and inadequate if you are doing more than simple object
persistence.

Objects in a relational system define domains. They are not struct definitions; they are
fully 'active' and support inheritance, polymorphism and encapsulation.

--
Lee Fesperman, FirstSQL, Inc. (http://www.firstsql.com)
==============================================================
* The Ultimate DBMS is here!
* FirstSQL/J Object/Relational DBMS (http://www.firstsql.com)<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Object-Oriented databases Reaerch