Re: Generic Modeling

In article <60360d48.0201022255.b17627a_at_posting.google.com>, Brian Smith says...
>
>> > 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.

As RDBMS initially didn't have recursion, the query language was actually less powerfull than procedural counterparts. On the other hand, SQL is higher level abstraction -- that might be what you meant by "powerful". Also, it is undoubtedly the simplicity of relational algebra (without recursion and nesting collections) that had driven overall RDBMS success. Now, we can't blindly throw additional constructs into the language and expect it to work, nor naively derive declarative language from a procedural one; so why do you think that "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.

In general, the more complex query language you have, the more chalenging query optimization is. Cost based optimisers are based upon evaluating the complexity of set operations. Any procedural code is a black box that optimizer cant make any reasonable guess of the associated cost. For example, how would you estimate the cost of

float totalPower = 0;
for( ElectricPlant e = plants.first(); e!=null; e.next() ) totalPower = totalPower + e.getPower();

? Exen if you change an explicit loop in this procedural code into some declarative collection operation, the ElectricPlant.getPower() method is definetely written with procedural code.

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

IMHO, so called "impedance mismatch" as an inconvenience for front-end object programmer is highly exagerated. Even though all application programmers are morons, I personally didn't see anyone unable to write jdbc code yet. Being unable to scale up the system as a result of rigid structure dependencies in the middle tier is a direct consequence of their naive perspective: "everything is an object".

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

Building one thing on the top of the other can't hardly be anybody's motivation.

Extending RDBMS with user programmed domains is a good thing, though, and happens slowly. Again, optimization significantly lags in that area.

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

Responding to James here.

Write generic solutions in OODB? What are you talking about? Nothing is more concrete than rigid containment hierarchy. Minor convenience of a familiar programming language is a generic solution?

I would like to see how would you query the equipment scattered at various levels of the hierarchy in OODB.

>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 ...
One more time, the more obscure concept of the language you use the more chances are that optimizer doesn't supports it yet. Hierarchical subqueries are not unnested by optimizer, for example.

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

Handling complex domains is not an area where relational would need any input from cowboy object programmers. Received on Thu Jan 03 2002 - 20:18:55 CET