Re: Generic Modeling
Date: 1 Jan 2002 10:16:13 -0800
Message-ID: <a6e74506.0201011016.42738ff1_at_posting.google.com>
> > 3 tables: things, properties and relationships.
> > Provided the flexiblity but the performance was insufficient.
>
> Was the performance bad no matter what you did?
Below were the tables used to model utility consumption of mfg
facility.
Only the significant fields are shown.
T_Obj
objId
objId_class
objId_parent
obj_name
T_Prop
propId
objId
prop_name
T_ObjProp
obj_prop_id
objId
objId_prop
op_value
T_ObjLink
objId_1
objId_2
In order to represent data in a very general manner, it seemed I wanted to eventually represent every thing with a unique id (objId). This gave much flexibility to represent complex data. However putting the information back together took considerable time even though nearly all the searches were based on clustered PKs. For example, in a normal design, John and his Age would be in a single row, but in the general design these two pieces of information would be in two rows, the second of which can only be looked for after finding the first. I think representing data in a very general manner in rdbs is closely related to representing hierarchal structures in a few tables.
> > Alternatively, XDb is a simple oodb that provides the type of
> Have you personally used this system for any projects?
It was the pursuit of a generic model and the insufficient performance of rdbs that led me to develop an oodb. It is simple and currently lacks the security/crash recoverability of the mature rdbs and thus is not yet appropriate for many applications. However it does allow one to create very complex and flexible data structures that which would be difficult in rdbs. Here is an example:
Allow any class (or sub class) of utility to be rolled up for any part to tree.
The above can be modelled in 15 minutes with XDb. See www.xdb1.com/Example/Ex046.asp Received on Tue Jan 01 2002 - 19:16:13 CET