Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)
Date: 2 Jun 2006 19:03:44 -0700
Message-ID: <1149300224.862586.229170_at_i40g2000cwc.googlegroups.com>
> DBD's data model is named TM. It's details are not being disclosed currently.
>
> Why would someone want to use a data management product with
> an undisclosed data model?
:) Because it 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-typeapps).
> Anyhow, because I'm a n00b and want to practice I will play with that example. (Note I'm not trying to /convince you/ of anything. Your tenor suggests that is not possible. Here is my relational database:
I was hoping for one of the defenders of the faith :) Maybe one will step in later to assist.
> Here is my relational database:
>
> colors :
> name part color
> ---- ---- -----
> john skin black
> john hair red
> john hair blue
> mary skin white
> mary hair red
>
> textures :
> name part texture
> ---- ---- -------
> mary skin smooth
> mary hair silky
> mary hair smooth
>
> Now for me this is easier to reason about than the hierarchy presented on that page
person name skin hair ----------- ---------- --------------------- ---------------------- AutoID# john black red-blue AutoID# mary white-smooth red-silky-smooth
Since a script was not provide for the relational implementation, 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 represenation 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. The only reliable mechanisms that allows a rmdb to guarantee they are the same is via normalization and key constraints. Dbd automatically "normalizes" data on the fly. Even though mary appears multiple times in the tree view, there is only one thing in the db which represents her.
Dbd doesn't suffer MV's flaw in implementing multiple values for an attribute (and I weclome the attempt to show it does). Among other reasons, MV is flawed because it can't provide data independent references to maintain integrity between similar values. The RM implementation above has a similar flaw between the multiple marys, but this situation is correctable in RM via proper normalization and key constraints.
(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 * colorpurple))) Received on Sat Jun 03 2006 - 04:03:44 CEST