Re: S.O.D.A. database Query API - call for comments

Lee Fesperman wrote:
> A query language that manipulates complicated
> structures like the linked trees you are alluding to
> is far more complex and difficult to use than relational ones.

How can you set up an absolute and final statement like this

- without knowing the usecase?
- without knowing how our final design will look like?
- without considering the possibilty that a GUI browser might pe placed on

> You say applications want to operate on trees of objects. This is fair
 enough, but they
> should be constructed on the client side (it could be an inner tier),
 using, for
> instance, an O/R wrapper. A manufacturing group is unlikely to need the
 same tree as
> accounting, or sales, even when accessing the same data.

Very true.
Accidentally you provided an excellent argument for OO here. This is what inheritence is used for.

> I'm talking about sharing persistent objects across multiple applications.
 OO structures
> fare poorly in such environments because there is no science here -- an
 object can be
> anything.

An object can always be broken down to simple type members with recursion. If we forget about the method part of objects for the time being, objects are links of simple data.

Where is the problem in sharing objects?

> You never responded to my comment that reusability of business objects has
> been a failure.

Has it?

I do agree with you here.
Programming languages and APIs pass by so quickly. Object models tend to get very specialized and large. A clean and lean rewrite for special usecases typically is more efficient. Ideally some of the old model and code can be conserved.

The same gos for the reuse of table models.

> You also have not told me how to distinguish a bad object design from a
> good one.

A good object design simply remodels reality.

Inheritance structures indeed are a problem. Reality uses multiple inheritence.

In programming languages, multiple inheritance can cause undefined behaviour and horrible complexity.

Possibly there is room for new concepts here.

A very high namespace resolution could be a solution. It would also increase the reusabilty of business objects.

> "These object guys are all Platonic idealists -- they
> think there's only one way to look at the world."
> But as database people, we know there isn't just
> "one way to look at the world."

I would take Platonic idealist as a compliment so I might be one in many respects.

With regards to querying a database, I do know that there are infinite views and I am idealistic enough to think this can be solved with an API. The future will tell about "Platonic" or not.

There are other "object guys" that argue "We don't need a query language. We can navigate from the root." As you can see by this thread, I am not one of those.

> > Using an object database you simply store the object, with no further
> > worries.
>
> I use relational techniques for designing a database shared by
 hetereogenuous
> applications rather OO techniques.

I have heard some bright people say that this is the wrong way around.

> > In a good object database you do not even have to worry how the objects
 get
> > put together. The database handles this for you.
> > - No work for the programmer.
> > - No sources of error.
> > - Higher performance.
> >
> > This is simplicity.
>
> The same arguments were given 30 years ago by hierarchical and network
proponents.

Again:
30 years ago programming languages where not object-oriented.

> Have you done the research on data models I suggessted?

No, sorry, I am being kept busy fighting all the SQL guys here.

....besides finishing off storage and query-by-example for n-dimensional arrays in db4o today.

> > > I was aware from the first where you were coming from, so my
> > > comments were not always directed to you alone.
> >
> > I know where I come from but I don't know what you mean here.
>
> I mean your mind was made up beforehand to persue this course, before you
 issued a "call
> for comments".

Now who's arguments are biased?

Actually I was looking for technical comments on the current design. Maybe somebody reading along might take a look after all: http://www.odbms.org/soda/soda.zip

Discussing the sense of the project really is of no great use because we will do it.

> Innovation needs to go forwards not backwards.
> You have not presented any proof that you
> are using an innovative data model rather than
> 30 year old techniques.

I think you are too biased with your own opinion to take a closer look.

Storage:

- define a class model of any depth
- with no administration work on the database engine side
- store a complex object with a single command

Was this possible 30 years ago?

Now why are you talking about the data model? If you question the sense of object-oriented programming then we really are from different worlds.

By the way:
In what language is firstsqlj programmed ?

> > Do you imply that SQL is and will be the standard forever?
>
> Egad, I would be the last one to wish that! SQL needs vast revamping to
 make it more
> relational. Relational also needs to evolve. Unfortunately, the SQL
 standards (1999-)
> are moving in your direction (co-opting your turf.)

Nice to hear!

Unfortunately Sun's JDO specification is totally headed in the wrong direction. They place Java code in string queries. This is where my journey started.

> I am very opposed to this. Look for
> my forthcoming article on SQL/MED:2000. It will be linked from
firstsql.com.

O.K.

> It is expensive enough to benchmark against SQL databases. We just don't
 have the
> resources to look at OODBMSs.

Believe me, it would be a 15 minute task to download the 200k ZIP file (includes our engine) and to enter the JDBC connection information. Tables are created on the fly.

If firstsqlj is available for free download, I might run a benchmark. Of course I would not publish any results without your permission.

Toby Downer, the maker of the McKoy database has tried our benchmark and he did not find anything wrong with it. It can also provide interesting figures for a simple comparison of relational databases.

Kind regards,
Carl

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