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

Carl Rosenberger wrote:
>
> Lee Fesperman wrote:
> > > - 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?
>
> How do you *know* that hierarchical and network databases suffer from broken
> links? Have you used one? I can't help other vendors bad implementations. A
> schema to model links between objects or tables is always as safe as the
> database engine. There is no difference between relational or object
> databases. If corruption occurs, joins or links are lost on both systems.

In the '80s, I used HP's Image (hierarchical) and ICL's IDMS (network) and am not aware of breaks that occurred during that use. I was referring to stories that were common in '70s when use of hierarchical and network systems was heavy.

At first you claimed your implementation was 'safer'; now you say there's no difference. As a general point, I'll agree with the latter. Now, the relational technique is definitely more complicated (internally), but it is mature technology.  

> > 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?
>
> How would you identify an individual employee within your company? You would
> use his first name and his last name. In very large companies you might also
> have an employee ID.

Apparently, you have some specific meaning for what a key is. Let me express it another way ... Your system has two ways of accessing data:

+ comparison of entity attributes, and
+ link navigation.

Relational only uses the first. Adding link navigation makes the query interface more complicated.

> > > 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.
>
> Again:
> We don't expose access by key at all.
> You can either
> - use a declarative query to get a resultset, that contains the desired
> objects
> or
> - navigate within the programming language from parent to child. This is not
> part of the query system. The object database only helps here since it
> regenerate links within an object network.
> Both methods are available for all objects.

Both methods are not available for all objects because (as you claimed) you remove keys. That means to access the sub-object using the removed key, you must access the parent object ... you can must use link navigation; it can't be accomplished by comparison of values.

> Again:
> Navigation within the programming language is part of the programming
> languages capabilities. We do not add complexity here.

No, instead you add the complexity at the query interface.

> > The complexity is --- First and foremost, the user must have knowledge of
 existing links
> > (and their direction) in order to access data.
>
> "Existing links" are defined by the class schema of the application.
>
> A programmer for a relational systema also has to be aware of the class
> schema of his application. *Additionally* he has to know the schema of the
> database. This is added complexity.

I agree. However, it is necessary complexity, otherwise you have a database that can't easily be shared ---- it is only usable by its 'native' application. All other applications, reports, ad-hoc queries must 'bend over backwards' to get the data.

> > Secondly, this brings more complications:
> > + access to a sub-object must be through a 'parent' object, a special
 complication in
> > some cases.
>
> Navigation between objects and members is alwys from object to member.
> The same gos for object-oriented applications that use relational databases.

Navigation inside the application is different from navigation through the database.

> > + deeper sub-objects require more knowledge and more complicated
> navigation.
>
> The same is true for relational databases: The more tables you join, the
> more complex a query gets.

In relational, you don't need to join the parent object and the sub-object in order to access the sub-object.

> > + 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."
>
> Accessing an entity from another entity always requires you to know how they
> are linked together.

The point is that your scheme forces the user to use the link even when you have no interest in the parent object.

> > > 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?
>
> What are foreign keys but relations between objects?

Ah yes, but the relational table columns that comprise the foreign key are simply values. They are not pointers to another object. The connection to other objects is meta-data that is not stored in the referencing table. To put it another way, a set of columns in a relational table could serve as the foreign key for several primary tables, which is impossible in your scheme. Relational can do this because the columns are simply data values not meta-data.

> > "> 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?
>
> When you use object variables within your programming language, they
> represent real world entities. Let's say I have an employee object with the
> name of "George Bush", that I have retrieved in a previous query: Now if I
> want to specify this object as a query constraint for another query, there
> are multiple ways of comparison. If I would want to retrieve all salary
> payments that match this specific "George Bush" I would use the
> constraint-evaluation "compare-by-object-identity". This is possible without
> exposing the OID.

It certainly helps to clarify things, though it does add a 3rd way of accessing things (accessing things by comparison of 'hidden' meta-data).

> > > 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?
>
> No, sorry, it just does not make sense to misuse an object database with a
> relational approach.

First you tell me that I can have what I asked for, then you tell me I'm misusing your system to do it that way. What is your story here?

> > 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.
>
> <caricature>
> This is wrong. Tell me exactly which paradigm stands in contrast to
> relational databases. How is redundant misplaced data prevented? Tell me
> exactly how you prevent it in relational databases, otherwise your databasee
> is likely to have it.
> </caricature>

Ha, Ha. Relational encourages and supports normalization, however, it can't force it. To quote Chris Date (see http://www.firstsql.com/dbdebunk/cjd7a3.htm):

"The DBMS can't enforce truth, only consistency."

Even so, normalization is a powerful tool for ensuring correctness in the database. You simply reject because it doesn't fit your scheme and replace it with vague concepts. When I ask you to explain how your concepts prevent redundant, misplaced data, you resort to 'caricature'. I assume that means you have no answer.

> Provided that you work with modern programming languages, relational
> databases require you to work with two programming paradigms:
> - object-oriented in your application class model
> - relational in your database scheme
>
> Using two paradigms makes an application more complex. This will result in
> - more errors
> - more implementation work = higher cost
> - worse performance

It sure does, but it's kind of unavoidable in a shared database. Relational provides several techniques that can reduce the application changes --- normalization, views, but it doesn't cover all cases (for instance, even in a pure relational system, some views are not updatable). You haven't mentioned anything in your system that attempts to reduce the burden.

> ...and of course more misplaced data.

Yeah, right. Let me see you back that statement up.

> > Normalizing the database greatly improves
> > the ease of extension.
>
> No.
> You have to extend two models:
> - the application class scheme
> - the database table system
>
> You also have to correct all queries and mappings by working through all
> applications by hand.

See above ... not in all cases, but definitely in some.

> > 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.)
>
> I will not dig down to your level of subjective negative argumentation. Your
> argumentation chain lacks any substance.

Those are the arguments have I presented throughout this thread ... you have simply failed to answer them ... here and elsewhere ----

+ It's harder to use because you have 3 methods of access which can only be used situationally.

+ It rejects normalization without providing any substitute.

You have no answer for that.

> > > 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?
>
> We have run benchmarks, memory tests and database file size tests against
> the following:
> - Oracle Light
> - IBM DB2 Everyplace
> - Cloudscape
> - Pointbase
> - Sybase SQL Anywhere
> - InstantDB
> - McKoy
>
> Our engine definitely is superior for many usecases, especially on
> low-resource OS-es like EPOC where you can not operate with memory-consuming
> object-relational wrapper libraries. Database storage implementation work is
> drastically reduced since you simply store objects as they come. We are
> absolutely sure that our engine is by far the best choice for storing
> objects on mobile systems. Slowly but steadily our mailing list grows with
> fans and supporters.

Your system is hardly more than an object caching system, with weak manipulative capabilities (compared to relational).

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