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

Carl Rosenberger wrote:
>
> Lee Fesperman wrote:
> > Carl Rosenberger wrote:
> > > 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".

I don't understand. How does a user place data 'ordered for joins' in a relational database? Greater than or less than joins are very useful, especially in self-joins.

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

I was just guessing about lost IDs; hierarchical and network databases suffer from broken links. In relational, these kinds of links are modelled with referential integrity. Can you prove that your scheme is safer, as you claim?

> - Primary keys do not model anything in the real world.

Primary keys often model the real world. They are used in the real world for identifying entities. They may be existing identifiers - social security numbers, policy id's, ... or values assigned by the system and used externally -- order #, employee id, ... . OIDs are not good for this. They are too long (too many digits) and, besides, are not 'exposed'.

Surrogate keys (similiar to OIDs) can be used in relational, but they should be used sparingly, because they have no real world meaning.

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

You are not removing the necessity for keys. How do you access top-level objects? Would your GUI require me to enter an OID in order to access the information for an individual employee?

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

You have two methods of access (by link, by key), but, some objects can only be accessed with one method and not the other. This is added complexity.

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

We're talking about query interfaces. In a relational query interface, the two basic elements are table and column within the table. There is no deeper level of reference. Link navigation (whether by qualification or by nested api) is a completely separate facility that does not exist in relational.

The complexity is --- First and foremost, the user must have knowledge of existing links (and their direction) in order to access data. Secondly, this brings more complications: + access to a sub-object must be through a 'parent' object, a special complication in some cases.
+ deeper sub-objects require more knowledge and more complicated navigation. + as the database becomes more complex, determining and understanding the required navigation becomes difficult -- "I know the entity I wish to access, but I'm unclear where it sits in the hierarchy."

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

That's one method of access (comparison of values). Link navigation is a second. You have 2 methods of accessing data; relational has one (comparison of values). Your system is more complex; it's definitely not the simplest way.

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

Relations between objects is meta-data. Relational doesn't store links between tables in the tables themselves, because it is meta-data. What is the real world counterpart to links? Paper clips, staples?

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

You left out the next quoted line of yours that I was responding to:

"> Navigation by links is *very* specific. We also want to provide the ability
> to specify comparison by object-identity in our query API."

I read 'comparison by object-identity' to mean you were exposing OIDs. What did you mean?

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

And will the user be able to use a foreign key and get key-type referential integrity?

> > > Relational databases use unnecessary techniques.
> >
> > You're adding unnecessary techniques - link navigation.
>
> Link navigation is essential to any object-oriented language.

On the client side, I have no problem with it. It just doesn't belong in the database or in the direct query interface.

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

Note: by 'misplaced data', I mean, for instance, that a member field is declared in the wrong object (class).

You said your database was not normalized. How do you prevent redundant, misplaced data? Tell me exactly how you prevent it, otherwise your database is likely to have it.

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

The above seems to be a justification for a database system that evolves via rewrite. For shared databases, this is rarely a luxury. Normalizing the database greatly improves the ease of extension.

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

You bet.

I'm sure that people will flock to a DBMS that is: + hard to use (multiple access techniques whose availability depends on the specific entity being accessed.)
+ untrustworthy (ignoring normalization will lead to redundant, misplaced data, which leads to data corruption.)
+ exensible primarily through rewriting rather than evolving (because it is not normalized.)  

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

You figure those constraints eliminate the possiblity of competition from a relational DBMS?

-- 
Lee Fesperman, FFE Software, Inc. (http://www.firstsql.com)
===================================================================
* Check out Database Debunkings (http://www.firstsql.com/dbdebunk/)
* "The Forum Where Database Matters Are Set Straight"