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

[David Orchard <orchard@pacificspirit.com>]

Reposting, appears to be some problem I have with my mailer.

Yet another viewpoint alert.  

The reason that I think that O-O is fading is because O-O required software
developers to make 1 assumption that turned out to be completely incorrect
for performance reasons.  That assumption is that the consumer of the
component does not know or care where the data in the component came from.
It turns out that consumers of components almost always care where the data
came from, such as an RDBMS.  So the one whole thing that the encapsulation
hid - where the data really is - turned out to be mostly unusable.  

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.  

Again, I tried on at least 5 different projects to build these re-usable
components but it just never happened.  Eventually I read the einstein quote
about insane people always trying the same thing and expecting different
results, and realized where I fit in the quote.

The great thing about XML is that it doesn't try to head-fake you into this
false assumption that some behaviour will auto-magically wrap the real data.
XML makes you think about coarser grained functionality, while giving you
really high productivity in creating your data or adapting your data from
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.  

I look at the single most effective way to continue developers productivity
increase is to raise the standardized component infrastructure as high as
possible - through things like XSLT, XQuery, and eventually processing
models and process languages.

Cheers,
Dave


> -----Original Message-----
> From: Al B. Snell [mailto:alaric@alaric-snell.com]
> Sent: Tuesday, May 22, 2001 7:08 AM
> To: Jonathan Borden
> Cc: Uche Ogbuji; Jeff Lowery; xml-dev@lists.xml.org
> Subject: RE: Picking the Tools -- Marrying processing models to data
> model s
> 
> 
> On Tue, 22 May 2001, Jonathan Borden wrote:
> 
> > The days of SQL databases are still today -- and what was 
> done then is still
> > proper. OO is still a great way to organize _software 
> modules_. The problem,
> > as I see it, is that software programmers, spending lots of 
> time designing
> > and writing software modules, start to try and view the 
> entire world as a
> > software module. Black box design was also around long 
> before "OO" and still
> > is the way to build stuff, what we need to keep straight is 
> when to use a
> > black box and when to use a clear box.
> 
> The principle of OO in data modelling is mainly to annotate the data
> directly with descriptions of valid modifications and data 
> extractions,
> rather than relying on all the clients to do it properly.
> 
> data-driven way: define your list of customers, and let 
> clients implement
> adding notes to a customer or finding the mean age of a 
> customer as they
> see fit.
> 
> OODBMS way: define the customer list, but clients do not see the
> representation; instead they see a list of operations on 
> customers, to add
> notes (but not to delete or change existing notes), and find 
> the mean age.
> 
> XML is just a data represention. You can have a 
> directly-client-accessed
> XML datastore with the customer data in, or you can have an 
> OODBMS that
> has an XML-RPC interface and may or may not use XML 
> internally as a data
> store. It doesn't really affect the above issues :-)
> 
> > 
> > -Jonathan
> > 
> 
> ABS
> 
> --
>  http://www.alaric-snell.com/  http://RFC.net/  
http://www.warhead.org.uk/
   Any sufficiently advanced technology can be emulated in software