Re: Generic Modeling

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

I agree that almost anything in oodbs could be also be represented in rdbs. For simpler data structures and relationships, a rdb is perfect and preferrable. For more complex data structures and relationships oodbs has to do nothing special or different because its basic design allows such flexiblity from the start. To continue the above example, to represent all possible hierarchy/arrangements of the 100 objects one might need the following tables:

T0, T1, T2, T3, T4, T5, T6, T7, T8, T9

T0_T1_map
T0_T2_map
T0_T3_map
T0-T4_map
T0-T4_map
T0-T5_map
T0-T6_map
T0-T7_map
T0-T8_map
T0-T9_map

unless you resort to a generic modelling within rdbs but then performance becomes a limiting factor.

> But, I would think that these relations could be built using "cutting
> and pasting" just as well as in an OODB.

Yes, but not as easily unless you resort to a generic modeling within rdb.
In XDb, it is o.CutPaste(NewParent) or in the interface Ctl+X (a nut or a battleship) and then Ctl+V
(http:www.xdb1.com/HowTo/CutPasteObj.asp) Where can I find this in Access, Sql Server, or Oracle?

> > > 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.
Maybe not but sometimes reality is that way and chaos is the norm not order

> Second, I would rather write one declarative query than write procedural code.
So would I and such is more possible when data is arrangable into a very structured tables as in rdbs.

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

Yes, concurrency is definitely a lacking in XDb.

> I think that other OODB's have elaborate query optimizers
> and surely can handle concurrent access.

They others may have "elaborate query optimizers" but still can't match the performance of XDb (www.xdb1.com/Benchmark) especially with complex/variable data. Is there a particular benchmark you would like to compare?

> 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 agree that generic modeling facilitates "generic coding". And I find that it is easier to write generic code with XDb than with rdbs.
For example, XDb implements the ability to instantiate/copy an object as simple as a nut to as complex as a battleship with all its dependent objects. The Instantiate/Copy/Paste buttons to do so appear in XDb's interface. The equivalent functions are available via the API. Where can I find these in Access, SQL Server or Oracle?

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

XDb is not a serialization of objects in a oo programming environment. XDb is a database like Access and SQL Server but much simpler and smaller yet more flexible and faster. XDb is accessible via a simple GUI interface and by programming environments capable of calling a DLL, for example VB, VB Script, ASP, C, C++, ASP, Delphi (www.xdb1.com/Dev/API).

> Futher, I don't doubt that a RDBMS could be built on top of an OODBMS;
Agree.

> similarly, I think that you could be an OODB system that stored
> information in an underlying RDBMS.

Could, but it would be difficult and slow since rdbs by design represent data using tables not objects. See above the difficult a rdb would have representing the 100 objects unless you resort to a generic tables in which case performance becomes a limiting factor.

> > 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 ...
Exactly, this can be done in an rdb when representing data in a few tables (aka generic modelling) but the performance is poor in comparison to XDb. If you are ready, we can try the "THING" table vs XDb on a battleship and compare the difference in flexibility and performance.

> > 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.
I you mean that an oodb results in more hand-coding, I would disagree.

Why is XDb able to instantiate complex classes? (www.xdb1.com/Basics/ClassComplex.asp)
(www.xdb1.com/HowTo/CreateObj.asp)
Because it is easier/possible to create the generic code for it.

Why doesn't Access, Sql Server, or Oracle provide the equivalent? I submit because it is difficult/impractical to do in a generic manner in rdbs (unless you resort to generic modelling of data).

Why is XDb able to copy any complex data structure? (www.xdb1.com/HowTo/CopyPasteObj.asp)
(www.xdb1.com/Benchmark/6.asp)
Because it is easier/possible to create the generic code for it.

Why doesn't Access, Sql Server, or Oracle provide the equivalent? I submit because it is difficult/impractical to do in a generic manner in rdbs
(unless you resort to generic modelling of data). Received on Thu Jan 03 2002 - 20:25:07 CET