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

Lee Fesperman wrote:
> > One further point on "the greater flexibility of ad-hoc joins" that the
> > relational guys have been arguing with here:
> > You seem to neglect that these joins have to be modeled into your tables
 in
> > the first place. Data also has to be stored using all theses keys. I
 have
> > pointed out the disadvantages and the negative performance implications
 of
> > key generation before.
>
> In ad-hoc joins, any columns may be used, not just 'modelled' keys.

Yes, but the data has to get into the database in some kind of ordered form, so "joins" make sense at all. Anything else would be a comparison for "equals".

> > Again:
> > What is the difference in linking objects by object-ids in comparison to
> > linking objects by relational keys?
> >
> > There is only one:
> > - Relational databases require maintenance of those keys by the
> > user-programmer. Relational databases require the specification of those
> > keys in query languages.
> > - Object databases handle both internally. They provide greater safety,
> > higher performance and reduce implementation work.
>
> + Relational keys are data (column values); OIDs are meta-data.
> + Relational keys are by nature bi-directional.
> + In a 'linked' system, access to sub-enities must be through a parent
 entity,
> complicating access and requiring special knowledge of the link structure
 (situational
> access).
> + OIDs don't model anything in the real world.
>
> Actually, an OID does model a real world thing - a paper clip, used to
 hold 'related'
> items. When the paper clip is lost, matching related items becomes very
difficult.

Again:
OIDs are not visible to the user, so why care about them at all?

To your comparison:
- Why should an internal ID get lost? There is more safety here than in a relational system.
- Primary keys do not model anything in the real world.

> > > You are discarding some core relational principles:
> >
> > Now isn't that wonderful?
> > Yes, we simplify things efficiently by using object databases.
>
> You don't simplify by adding complexities. If you want pre-linked
 entities, use
> relational views. If you want view optimization, use a FirstSQL RDBMS.

Where do I add complexity? I am removing the necessity for keys. The result is simpler.

I can't follow your argumentation. For me it sounds like: "If you walk withouth crutches, walking becomes more complex."

> "We don't provide you with links ...", but "We provide a means of getting
 them back -
> navigation through links". I figured. My problem is with 'navigation
 through links'. You
> have two methods of getting to objects (in a definitive way):
> + link navigation, and
> + by key.
>
> That's the complexity -- twice as many ways as relational. I called link
 navigation
> 'situational' because it can only be used in certain situations. It may
 also require
> that you access top level objects to get to lower level objects. That's
 the loss of
> power.

No sorry, if you use an object-oriented language, object databases do not make things more complex. You always have navigation, even if you use a relational database. Navigation is the notation: object.member.member

This is part of the programming language and not specific to the object database.

Object databases provide the simplest way of persistent storage of objects that are used by the programming language. There is no limitation on the possibility to use highly complex object networks.

In addition object databases provide a means of querying stored objects. Querying should not take place "by key" as you write here. Internally used keys can remain transparent to the user.

Querying should take place by identity comparison or by comparison of properties.

> > Meta-Data is represented by the class definitions.
> > Data is represented by objects.
>
> Your 'links' are meta-data and are mixed with regular data.

No, links are not meta-data.
Links are relations between objects.

Under "meta-data" I would understand data that describes the class model.

> > You may model your classes in any way you wish. Of course you can add a
> > field "ID" and set a value "1", if you find this necessary for your
> > application.
>
> Exposed OIDs? I thought you said- "We don't provide you with links...".

No, sorry, I do not suggest exposed object IDs. Object IDs are handled internally.

I only wanted to point out, that the user can do anything he wishes in modeling his objects. If he feels that he needs a "primary key" for object types, he can of course add one.

> > Relational databases use unnecessary techniques.
>
> You're adding unnecessary techniques - link navigation.

Link navigation is essential to any object-oriented language.

> What is your reason for replacing a fundamentally sound data design
 technique with a
> bunch of vague concepts (an object can be 'anything')? You database is
 likely to
> contain:
> + redundant (and possibly conflicting) data, and
> + misplaced data.
>
> and be hard to evolve (just re-write).

All of the above statements are completely without any basis or value. Analogies:
"The earth is the center of the world. The earth is flat. If you sail too far, you will fall of the edge."
"Relational databases are the center of the world. Data needs to be flat. If you use object databases, you will get redundant, conflicting and misplaced data."

> In other words, you rewrite instead of extend.

The above point started out with reuse. I do agree that reuse still is a great problem in application development. Programming paradigms simply move to fast. Depending on the application, rewrite cycles typically are somewhere between 3 and 10 years. Very rarely you would use the same development technique a second time. This is where you rewrite comletely.

Within one development you of course extend existing models. This is where one of the great features of object-orientation is of great value: inheritance

Object databases support inheritance without the need to worry about keys.

> Is that what your are aiming your system for, specialized niches?

The power of object databases will finally succeed in all areas where object oriented languages are used.

If you ask me personally, yes we do specialize on a niche: We are targetting mobile Java devices with limited memory and resources.

Kind regards,
Carl

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