Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: Generic Modeling

Re: Generic Modeling

From: Brian Inglis <Brian.Inglis_at_SystematicSw.ab.ca>
Date: Thu, 03 Jan 2002 10:58:15 -0700
Message-ID: <0i783uss91bbl2pandt1o2sbdft4v0chfv@4ax.com>


On 2 Jan 2002 18:52:08 -0800, jraustin1_at_hotmail.com (James) wrote:

>> Writing object database is easy,
>An oodb should be more difficult since it is trying to represent and
>manipulate data in a more generic manner than in rdbs. For example in
>XDb, one can create 10 instances of 10 classes and arrange the
>resulting 100 objects in any imaginable hierarchy/arrangement (by
>simply cutting and pasting). An rdb is not as flexible.
>
>> the only thing you need to master is recursion.
>Does this bother you?
>
>> No query parser,
>When the above 100 objects can be arranged as randomly as in an oodb
>(or generic table design), traditional sql does not apply very well
>since it relies on rigid structuring of the data. Object based "sql"
>does exist but it is not a powerful as traditional sql (yet).
>www.xdb1.com/Basics/Query.asp
>www.xdb1.com/HowTo/CreateQuerySimple.asp
>www.xdb1.com/HowTo/CreateQuery.asp
>
>> no optimization
>An oodb can be 10 to a 100 times fasters, especially when dealing with
>complex/variable data. Would you like to benchmark a specific example?
>Last time I couldn't get you to engage, you were very recursive.
>
>> no concurrency.
>You are correct. Currently none in XDb. Can't say for others.
>
>> After serializing the whole memory to disc
>> you just claim that you have (yet another) object database!
>This must be very troubling since the concept of representing data as
>objects is unimagineable.
>
>> Therefore, when you want to search for all broken(?) standard components
>> you write:
>>
>> for( Country a = countries.first(); a!=null; a.next() ) {
>> State[] states =a.states;
>> for( State s = states.first(); s!=null; s.next() ) {
>> City[] cities = s.cities;
>> // 10 more levels to get to standard equipment
>> }
>> }
>> ..
>
>If the data fits "neatly" into rectangle tables and the relationships
>are rigid, then the traditional use of an rdb is best. Generic
>modeling or an oodb begins to show advantage as data complexity and
>variabililty increases. The above rigid loops would work well on data
>that have a rigid structure.
>But if the equipment are scattered at various levels of the hierarchy
>and some of the levels are missing and the situation is different for
>each manufacturer the above rigid loops don't provide a generic
>solution. With a generic table design or an oodb approach, it is more
>often possible to write generic solutions.
>
>If you can implement a generic deep instantiate as in XDb using an
>rdb, I would like to see it. (www.xdb1.com/Basics/ClassComplex.asp)
>
>If you can implement a generic deep copy as in XDb using an rdb, I
>would like to see it. (www.xdb1.com/HowTo/CopyPasteObj.asp)
>
>If you can implement a generic property rollup as in XDb using an rdb,
>I would like to see it. (www.xdb1.com/UI/Rollup.asp)
>
>The traditional use of rdbs is the best solution for most problems,
>but if you try implement the above you may begin to see the need for
>generic modelling/oodb approach.

OODB == old Codasyl network database in sheep's clothing consistency, maintenance and scalability are a bear don't hold your breath for solutions -- RDBs are available

Thanks. Take care, Brian Inglis Calgary, Alberta, Canada

-- 
Brian.Inglis_at_CSi.com 	(Brian dot Inglis at SystematicSw dot ab dot ca)
    fake address		use address above to reply
tosspam_at_aol.com abuse_at_aol.com abuse_at_yahoo.com abuse_at_hotmail.com abuse_at_msn.com abuse_at_sprint.com abuse_at_earthlink.com abuse_at_cadvision.com abuse_at_ibsystems.com uce_at_ftc.gov
						spam traps
Received on Thu Jan 03 2002 - 11:58:15 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US