Re: Clean Object Class Design -- What is it?

Bob Badour wrote:
> >- on person in one column of one row
> >- one address in another column of another row
>
> Your example is absurd, of course. If you wanted to associate an
 independent
> person with an independent address, you would put them in two columns in
 the
> same row. Duh!

Fine.
What mechanism would ensure that
  person.address
is set, after retrieval of the two objects from the two columns of one row in your database?

What happens with your concept if a person can have two addresses?

> >Would the database know, how to do this automatically?
>
> Because someone told it to. How does your product do it automagically
> without anyone ever telling it to?

Objects are associated by class-member relationships in running code. This is the association we preserve and restore.

> >Object databases do not need to worry about "encapsulation". Every object
 is
> >stored as such with full rights.
>
> As it is in a relational database. Your point would be...?

Your approach of storing objects to columns of rows does not provide access to "encapsulated" objects individually.

> >> >An OO application links many objects together. I would like to
 preserve
> >> >these links and restore them.
> >> >...like person and address...
> >>
> >> A tuple links many objects together. Each object can have arbitrary
 internal
> >> complexity. What is your point?
> >
> >Where is the borderline?
>
> Between what and what?

Storing objects to columns of relational databases just does not make sense. There is no concept, what to embed into these objects. "Encapsulation" looses all the advantages of ad-hoc-wild-querying that relational databases have.

> >Assume that you have an object network of 10,000 objects, all linked
> >together by class-member relationships.
>
> Are these internally encapsulated? Or externally related?

With an object database you do not need to differentiate.

> If they are internally encapsulated within a single object, then one only
> needs to deal with the single object.

Do you really want to store 10,000 objects to one column of one row of one table? Would you call this concept data management? It is just a way of misusing the blob capability of your relational database to store a file.

> If they are not internally
> encapsulated, why would your product treat them as a single unit in the
> first place?

The concept's name is "persistance by reachability". It minimizes implementation work and maximizes speed.

> >I would like to query for each object individually and I would like to
 start
> >instantitating the object network from the objects returned by the query.
 I
> >definitely don't want multiple instantiations of the same object. If
 another
> >query has previously returned one of the objects I am interested in and
 my
> >application is already working with it, I want a reference to this
 object,
> >not a duplicate.
>
> So? And your point would be?

Restoring objects exactly in the same way as they were stored, with all class-member relations restored.

> >> >I also want to make sure, that a stored object is only
> >> >instantiated once.
>
> That would be an issue in the application and not an issue in the
 database.
> If the database properly supports domains, it should be no problem
 assigning
> an object value to an object variable in the application.

Why should every single application developer individually have to develop a concept of identifying objects and associating them with relational keys, if the database engine can take care of the job?

> >How does a relational database ensure, that an object is put together
 only
> >once and that the following queries return this
> >one-and-only-individual-object?
>
> Since the object variable has an identity established by the relation
 name,
> column name and corresponding logical identifier, how would it not?

Please provide an example of an engine that provides this feature.

> This is a product dependent, implementation dependent issue. If your
 product
> requires a lot of time, I guess that means your product requires a lot of
> time. Do you have a point?

The Java virtual machine consumes a fixed time to instantiate objects which has nothing to do with our product. Using byte representations for query comparisons is faster and that is why we do it.

Yes, I do have a point.
I am referring to your approach of using methods-of-objects-stored-to-columns-of-rows-of-tables for queries. Objects need to be instantiated to provide this feature, which is slow.

> I have already demonstrated that relational
> databases are unquestionably OO.

This statement is simply absurd.

You where talking about storing 10,000 objects in one column-of-one-row-of-one-table with no associative context, no adequate querying fuctionality, slow performance, no maintenance features, no identity functionality to ensure single instantiation, no representation of inheritance structures and neither memory- nor instantiation management.

Your "ideal" construct is not a very good design, in my humble opinion.

Relational databases unquestionably are not object-oriented.

Kind regards,
Carl

---
Carl Rosenberger
db4o - database for objects - http://www.db4o.com