Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

From: Neo <neo55592_at_hotmail.com>
Date: 3 Jun 2006 16:42:49 -0700
Message-ID: <1149378169.238237.231040_at_i40g2000cwc.googlegroups.com>


> PS. Note that, as pointed out before, I'm new to this. So if I've made basic mistakes please excuse me cdt.

No problem.

> First, your peculiar placement of smilies in this post and others comes across to me as condescending. Is that your motivation?

No more smilies :(

> > [dbd's data model] is more general/flexible/systematic than other data models including RM and excels in applications where 1) data structure is complex/variable 2) future data requirements are unknown 3) and minimum impact on schema/queries/code is desirable (ie AI-type apps).
> how can one verify your claims 1-3 if the data model is hidden?

Through examples.

> Is there a way to analyze a hidden data model?

Yes, via various examples.

> Or must we spend time inferring the data model from your particular DBMS interface?

This is your option.

> > Actually the data model was described in cdt for several years and people like Alfredo and Bob concluded it couldn't possibly work.
> Interesting, can you point me to some subjects or links?

Search for Neo during the past 5 years in cdt/cdo.

> I have no idea what "faith" you are referring to.

RM.

> Is it the same "faith" one needs to believe claims about an /undisclosed/ data model?

Not quite, one can verify my claims via examples.

> > Since a script was not provided for the relational implementation,
>
> I'm getting a little confused here. Remember I'm new to this lingo. What is a "relational implementation"? Is that a synonym for database or DBMS?

Yes. (Tech talk to keep the RM police happy)

> colors :
> name part color
> ---- ---- -----
> john skin black ...
>
> Is what I presented correctly called a database?

You might get arguments either way. I'll say it is according to my definition which is a system for managing data. Each system has its advantages and disadvantage that can vary for different situations. If one is representing a few people with distinct names, your system might be ideal.

> > I will assume the underlying data is structured in two tables as shown above. As such, we can't even begin to make a valid comparison as the data in the relational implementation is not normalized where as there are no redundant representation of things in dbd's. For example, in the relational implementation mary is represented in two tables and in multiple rows and db has no reliable method of knowing that they are the same.

> I don't understand this language. What are "things"?

Anything is a thing. Thing is the highest abstraction of everything. Things are instance of thing. A car is a thing. A person is a thing. An idea is a thing. A table in a db is a thing. A row is a thing. A values is a thing. A symbols is a thing...

> mary a thing?

While mary may or may not be a person, a girl, a human, a value, etc; I simply refer to her by the highest abstraction. Mary will alway be a thing.

> In the model above isn't mary just a value in domain name?

Each data model has it's own language / definitions. If you would like to classify mary as a value in context to RM and described tables, that is fine by me.

>> Now suppose, we want to add a second person also named mary but with purple hair. Dbd handles this situation without restructuring the original data.

> Hmm ... well your(?) dbd seems to automatically generate an unique ID, yes? A7FB etc? That was something I just missed in the website example originally.

Actually you didn't miss it. In dbd, the user never needs to specifes an ID when entering/retreiving/manipulating data. There are no IDs in dbd's scripts. The ID is not part of the schema. In RMDB, the equivalent ID might be the memory address associated each row.

> Trivial to correct the design to include this. RDBMS products regularly provide such automatic unique ID's if you want them as well.

> colors :
> person name part color
> ------ ---- ---- -----
> A7FB john skin black
> A7FB john hair red
> A7FB john hair blue
> AD2E mary skin white
> AD2E mary hair red

> textures :
> person name part texture
> ------ ---- ---- -------
> AD2E mary skin smooth
> AD2E mary hair silky
> AD2E mary hair smooth

One can't use an autoID because each row would have a different ID. And autoIDs are usually only in context to one table. Now the RMDB user needs to 1) specify an ID value which has not been specified before in either table 2) and may be responsible for entering the same ID value in two tables

In order to make a more valid comparison, we should be comparing scripts. Below is the script to enter a new person named mary who has purple hair and black skin. Could you post the equivalent script for the relational implementation? What I want to see is how it will handle the IDs? Maybe an RM expert can assist.

(create hair instance (new))
(create (it) color (select+ color instance 'purple))

(create person instance (new))
(create (it) name (word+ 'mary))
(create (it) hair (and (select hair instance *) (select * color
purple)))
(create (it) skin (and (select skin instance *) (select * color black)))

Also, the relational implemenation gives me the impression the level of "normalization" in dbd's example was not obvious. Please take another look at the www.dbfordummies.com/Example/Ex005.asp as I have update the figure to make this aspect clearer. In particular, observe that instances of hair, skin, color and texture are "normalized". Received on Sun Jun 04 2006 - 01:42:49 CEST

Original text of this message