RE: Picking the Tools -- Marrying processing models to data model s

["Al B. Snell" <alaric@alaric-snell.com>]

On Tue, 22 May 2001, Orchard, David wrote:

> I don't know how many times I personally tried to write objects and classes
> on top of RDBMS, file systems, etc. and then found that they had to all be
> tuned for performance reason.  A great example is a small set of components
> - say ejbs? - that wrap a set of SQL tables.  Most people write a class for
> each table, and roughly an object for each row.  Now the problem is that SQL
> has these GREAT query operators that can do joins and move a whole bunch of
> logic into the server.  But that doesn't work with my great component model.
> So there's one style of objects for "read-only" and another style of objects
> for read/write.  Which is really wierd.  And it gets wierder and less
> encapsulated when I want my web site to disable all functionality that's
> related to a particular database when I do my data ware extraction.  

That's impedance matching - you're emulating on OODBMS on top of an RDBMS,
and suffering the consequences :-)

> one system to another.  To me, the biggest benefit of XML is that sooo much
> functionality is pushed into parsers, processors etc.  That means developers
> can make re-use of these coarse grained components in a very high
> productivity environment.  

That's nothing unique to XML... an OODBMS does pretty much the same thing
in that context. You model your data, with the joys of structured types
and inheritance to help model things that SQL is lame at, and it handles
the rest. You can stick with the default interfaces to get and set fields,
or close those off by making the fields private and providing methods to
access them in specialised patterns.

ABS

-- 
                               Alaric B. Snell
 http://www.alaric-snell.com/  http://RFC.net/  http://www.warhead.org.uk/
   Any sufficiently advanced technology can be emulated in software