Re: Generic Modeling

jraustin1_at_hotmail.com (James) wrote in message news:<a6e74506.0201021852.2ba431d7_at_posting.google.com>...
> > 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.

Well, I don't think you can say that. You might say that the OODB's DDL is simpler in this example because the relational version will require 10 tables and one relation for each "hierarchy/arrangement". But, I would think that these relations could be built using "cutting and pasting" just as well as in an OODB.

> > 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

First, 100 randomly arranged objects are not very useful. Second, I would rather write one declarative query than write procedural code. But, I don't think that RDBMS has a theoretical advantage in this area because I think that an OODB could have a declarative query language as powerful as a RDBMS's query lanugage.

> > 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.

I think the point is that the DBMS should be responsible for the optimization and concurrency. This is criticism of the XDB implementation, not of OODB's in general. I think that other OODB's have elaborate query optimizers and surely can handle concurrent access.

> 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.

Well, I think that generic modeling is best used to facilitate meta-programming (automatic creation of programs) and "generic coding". By "generic coding" I mean writing a small amount of (more complex) generalized code that significantly reduces the amount of relation-specific (class-specific) code you have to write. This is orthogonal to the OODBMS vs. RDBMS argument.

I would say that an OODBMS has an advantage over an RDBMS when you are using an OO programming language for logic AND your serialization needs can be handled (nearly) transparently and efficiently by the OODBMS. An RDBMS has the advantage when your data has to be accessed by a non-OODBM system.

Futher, I don't doubt that a RDBMS could be built on top of an OODBMS; similarly, I think that you could be an OODB system that stored information in an underlying RDBMS.

> 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.

I agree the last sentence, but I think the example of having a lot of varience in the dealings of things belongs more in an argument of "code vs. data" and/or "declarative vs imperative".

> 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)

I know you can do this really easy by using a "THING" table in SQL, because I have already created something like that using two tables. For the deep copy it helps to have a recursive query operator like the Oracle "CONNECT BY". Then you just do an INSERT INTO ... SELECT ... CONNECT BY ...
> 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.

RDBMS vs. OODBMS is orthogonal to generic vs. hand-coded.

Thanks,
Brian Received on Thu Jan 03 2002 - 07:55:02 CET