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

Carl Rosenberger wrote:
>
> Lee Fesperman wrote:
> > A query language that manipulates complicated
> > structures like the linked trees you are alluding to
> > is far more complex and difficult to use than relational ones.
>
> How can you set up an absolute and final statement like this
> - without knowing the usecase?
> - without knowing how our final design will look like?
> - without considering the possibilty that a GUI browser might pe placed on
> top of the API?
> - without giving our approach a chance? Have you tried setting up a
> "statement"?

Research has shown that a query language based on pointers are less powerful and harder to use.

> > You say applications want to operate on trees of objects. This is fair
 enough, but they
> > should be constructed on the client side (it could be an inner tier),
 using, for
> > instance, an O/R wrapper. A manufacturing group is unlikely to need the
 same tree as
> > accounting, or sales, even when accessing the same data.
>
> Very true.
> Accidentally you provided an excellent argument for OO here.
> This is what inheritence is used for.

Even though the data is the same, you will make separate objects for each department? That only makes sense on the client side.

> > I'm talking about sharing persistent objects across multiple applications.
 OO structures
> > fare poorly in such environments because there is no science here -- an
 object can be
> > anything.
>
> An object can always be broken down to simple type members with recursion.
> If we forget about the method part of objects for the time being, objects
> are links of simple data.
>
> Where is the problem in sharing objects?

If they are written for one application, it will be hard for a different application to use it.

> > You never responded to my comment that reusability of business objects has
> > been a failure.
>
> Has it?
>
> I do agree with you here.
> Programming languages and APIs pass by so quickly.
> Object models tend to get very specialized and large.
> A clean and lean rewrite for special usecases typically is more efficient.
> Ideally some of the old model and code can be conserved.

This is why objects are poor models for long term data storage.

> The same gos for the reuse of table models.

You have no basis for making that statement. Extending an existing database is easier in the relational 'table' model that any other data model.

> > You also have not told me how to distinguish a bad object design from a
> > good one.
>
> A good object design simply remodels reality.
>
> Inheritance structures indeed are a problem.
> Reality uses multiple inheritence.
>
> In programming languages, multiple inheritance can cause undefined behaviour
> and horrible complexity.
>
> Possibly there is room for new concepts here.
>
> A very high namespace resolution could be a solution.
> It would also increase the reusabilty of business objects.

Compared to the proven power of normalzation, this is not very comforting who must bet their data resources on this technique.

> > > In a good object database you do not even have to worry how the objects
 get
> > > put together. The database handles this for you.
> > > - No work for the programmer.
> > > - No sources of error.
> > > - Higher performance.
> > >
> > > This is simplicity.
> >
> > The same arguments were given 30 years ago by hierarchical and network
> proponents.
>
> Again:
> 30 years ago programming languages where not object-oriented.

You have been describing a pointer based model of storing and retrieving persistent data. That's exactly what hierarchical and network are, and it is their downfall.

> Storage:
> - define a class model of any depth
> - with no administration work on the database engine side
> - store a complex object with a single command
>
> Was this possible 30 years ago?
>
> Query-By-Example:
> - create another object and set all members that you want evaluated against
> the stored objects (declarative!)
> - with one single command
> - retrieve all objects that match the example
>
> This is working *now*.
>
> Was this possible 30 years ago?
>
> Now why are you talking about the data model?
> If you question the sense of object-oriented programming then we really are
> from different worlds.

A data model is a technique for storing, maintaining and retrieving data, so you do have a data model. It is obviously pointer based, hence I have talked about the problems with pointer based systems and query languages built on them.

> By the way:
> In what language is firstsqlj programmed ?

Java --- for portability reasons. The algorithm is far more critical than the implementation language.

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