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

... been offline for a few days --- my news server has been feeling poorly.

Carl Rosenberger wrote:
>
> Lee Fesperman wrote:
> > > For the moment we are not competing with ad hoc queries typed into a
> > > console. As I posted here before, a text-based ad hoc query language
> > > would be built on top of this API.
> >
> > It won't be sql, since you eliminate keys (as you implied below). You'll
 need some
> > non-sql notations to navigate. Of course, you'll still need to support
 ad-hoc joins
> > based on common values.
>
> I would call your "ad-hoc joins" equality comparisons.

They are not limited to equality comparisons.

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

I believe the 'keys' you are referring to are primary keys and foreign keys. These are modelled during normalization. All other (non-primary and non-foreign key) columns may be used for joins but are not 'modelled'. I don't think I neglected to mention normalization.

> > Since you are connecting entities without keys (as you
> > imply below), you must be connecting them together 'physically' by
 physical proximity or
> > by some type of link/pointer/reference. It is this general way of
 connecting entities
> > that I object to. In fact, I object to any way of linking entities (in a
> > shared database) that is not based on common values (keys).
>
> Why?
>
> 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, 

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.

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

> > + All information in a database is represented by values in table columns.
> > + Every data element in the database can be (uniquely) accessed using 3
 pieces of
> > information:
> > - table name
> > - primary key
> > - column name.
> >
> > In your database:
> > + Some information is represented by links/pointers/references (this is
 meta-data --
> > data about data), and
> > + Some data elements can only be accessed by following those
> links/pointers/references.
>
> Wrong and wrong. We don't provide you with links/pointers/references, so why
> do you care about them? When you drive a car, to you need to care about the
> internas of how the fuel gets into the carburettor?
>
> You pass objects to the database. We take them apart for you and index them
> and make sure that everything is fast. We provide two means of getting them
> back:
> - navigation through links
> - a declarative query interface, very well suited for programmatic usage in
> object-oriented languages

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

> > This means:
> > + There is more than one type of information - data and meta-data, and
>
> Meta-Data is represented by the class definitions.
> Data is represented by objects.

Your 'links' are meta-data and are mixed with regular data.

> Separation could not be more beautiful.
>
> > + There is no single way of retrieving specific data elements.
>
> 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.
>
> Navigation by links is *very* specific. We also want to provide the ability
> to specify comparison by object-identity in our query API.

That's right; it's specific, not general. Link navigation is not available to all objects and is different in different situations.

Exposed OIDs? I thought you said- "We don't provide you with links...".

> > You have replaced single techniques with multiple 'situational'
> techniques.
>
> What's a "situational technique"?

See above.

> Relational databases use unnecessary techniques.

You're adding unnecessary techniques - link navigation. What are you eliminating - normalization?

> > Research has shown that access (by any query interface) is more complex
 and less
> > powerful in this circumstance.
>
> How can you research something that has not even been designed yet?

Link navigation in shared databases has been researched heavily.

> Where is power lost and for what?

See above.

> > But your objects are not normalized. They can't be because they contain
> meta-data.
>
> No, indeed objects are not normalized since we don't need this step in
> object databases. This is the great advantage.

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

> However objects do not contain meta-data. The class schema is stored as an
> object of its own.

Links are meta-data --- data about data.

> > > Typically object models are more precise, so they are cleaner, smaller
 and
> > > more reusable.
> >
> > Last posting, you agreed with me that reusability of business objects is
 poor.
> > Relational tables are easier to extend precisely because they are
> normalized.
>
> Agreeing with you seems to be a bad idea, since it will be used against me
> in the future. :-)
>
> I was referring to two ways of reuse:
> - Complete reuse, which is typically poor.
> - Partial reuse of code, which will typically better, the smaller objects
> are.

In other words, you rewrite instead of extend.

> How does normalization improve extension capabilities?
> Normalized or not, you add a column to a table or a field to an object.

It's useful to know which table/object should be extended and whether a new table/object should be created to hold the 'column'.

> > > What is the pratical difference between linked objects and table rows
 joined
> > > by keys? Keys add unnecesserary complexity without any further
 advantages.
> >
> > That is exactly the argument presented by hierarchical and network
> proponents.
>
> They were right with this point.
> Where is your counter-argument?

Now, that's a tough one. I have presented the technical arguments and pointed you to wev resources. Let's try it another way --- relational has walloped them in the marketplace:

+ Hierarchical:

• IMS, IBM's former flagship database (replaced by DB2)
• Image, HP + Network (also known as Codasyl):
• IDMS, various vendors including ICL.

These systems are still in use but are in the database backwaters.

There is a more modern system - born as Raima DB, now know as mBrane. They are successful in certain niches. Is that what your are aiming your system for, specialized niches?

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