Re: S.O.D.A. database Query API - call for comments
Date: Tue, 8 May 2001 14:07:51 +0200
Message-ID: <9d8nkr$mj$02$1_at_news.t-online.com>
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.
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.
> 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:
There is only one:
What is the difference in linking objects by object-ids in comparison to
linking objects by relational keys?
- Relational databases require maintenance of those keys by the
- Object databases handle both internally. They provide greater safety,
higher performance and reduce implementation work.
> You are discarding some core relational principles:
Now isn't that wonderful?
Yes, we simplify things efficiently by using object databases.
> + 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?
Object databases may use different types of implementations. They could even store objects to relational databases in the background.
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 want to extend the declarative query interface step-by-step to provide a superset of SQL. Declarative updates for maintenance reasons have been suggested in this thread.
Again:
Why would you want to worry about implementation details? Which problem do
you want solved?
We put objects back together and make sure that all objects are joined exactly in the same way as they were stored. We make sure that this also works if you retrieve the same object multiple times with multiple queries: You get one object back and multiple references to this object.
> 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.
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.
> You have replaced single techniques with multiple 'situational'
techniques.
What's a "situational technique"?
Relational databases use unnecessary techniques.
> 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? Where is power lost and for what?
> > Relational table functionality is a subset of object functionality.
>
> That's one way to say it. I prefer to say that relational table data is
normalized, and
> object data is probably not ---- for instance, it may not have a primary
key.
As above:
Feel free to add any member you wish.
If a member "primary key" makes you happy, add one to your class and use
your good old relational generation methods to ensure it counts correctly.
> 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.
However objects do not contain meta-data. The class schema is stored as an object of its own.
> > 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.
> > 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?
Kind regards,
Carl
--- Carl Rosenberger db4o - database for objects - http://www.db4o.comReceived on Tue May 08 2001 - 14:07:51 CEST