Re: [Gnue-dev] Why the Object metaphor? (Was: Object-Relational Mapping?)

[Neil Tiffin]

Jason,

At 12:17 PM -0600 1/18/03, Jason Cater wrote:
> oranges. Why can't the underlying relational data be abstracted to a more
> user-friendly level, but without the use of objects?

Please re-read my comments.

> At 6:00 AM -0500 1/17/03, Neil Tiffin wrote:
> > On Thu, Jan 16, 2003 at 06:34:02PM -0500, Neil Tiffin wrote:
> > >  I think the goal should be a simple to understand method of modifying
> > >  the system behavior by non information systems professionals.  An
> > >  object model (implemented well) is easy to explain to someone who is
> > >  not up on the latest OODB vs relational issues.  One can talk about
> > >  purchase order objects, sales orders etc.  In the relational world it
> > >  real easy to lose the abstraction because of the need to normalize
>  data.

I said it is "easy to lose the abstraction".  That does not mean that 
it is always done or that with the relational model abstraction is 
impossible.  Sorry I ticked you off by using the term "Object Model" 
instead of more properly calling it "Business Object Model"  or just 
simply "Business Model" in the above paragraph.  Close reading of my 
other comments should have given a clue as to my meaning but I did 
mislead a bit.

In my experience, talking loosely about business objects is intuitive 
and easy to understand for a lot more people than tables, rows, 
columns, foreign keys, indexes, constraints, select statements and 
etc.   This also not talking about software object model with methods 
etc.

At 12:17 PM -0600 1/18/03, Jason Cater wrote:
> real kicker of that statement is the jump from abstracting into objects,
> to discussing why the low-level relational model is too complex for the
> end user because of the need to normalize data. That's comparing apples to
> oranges. Why can't the underlying relational data be abstracted to a more
> user-friendly level, but without the use of objects?

The reason for the jump (apples to oranges) was because I was not 
talking about just "discussing" but about modifying system behavior 
(the first sentence of mine that you quoted).  You can not do that in 
the non-abstracted SQL system without making the jump to the low 
level relational model.  With an abstraction you should be able to 
make certain and hopefully many types of modifications without making 
the jump into the detail implementation model.

And referring to the above quote, I said nearly the exact same thing here:

> > At 6:00 AM -0500 1/17/03, Neil Tiffin wrote:
> > >  There is no question that the relational model is useful, well
> > >  understood, effective and may even be the best technical solution.
> > >
> > >  But whatever you call it, I think an abstraction above the relational
> > >  database (or OODB) model is needed to make enterprise apps killer

I am not repeat NOT NOT saying that we need an technical or software 
object model.  Simply the more the complexity is reduced for the user 
and the more closely it resembles the business the more applicable 
the solution will be to more users.  This is the abstraction i am 
referring too.  And I referred to "may be the best technical 
solution" because i am not arrogant enough to think that I know all 
of the possible solutions, not because I think objects may be better.

At 12:17 PM -0600 1/18/03, Jason Cater wrote:
> Now, to really play devil's advogate.  My accountants DON'T understand
> object terminology. If I start discussing Purchase Order objects, I'm

Your accountant does understand business objects.  That is all they 
really deal with.  I would agree that they probably don't understand 
the object model, but that was not what I was referring too.  But if 
you start discussion Purchase Orders they will understand.  The more 
closely GNUE models the business world the more people will use it.

I don't know why you want to put me in the information system object 
camp as I really don't care about the underlaying technology and 
never have.  If you tell me what term is politically correct to use 
to refer to a purchase order or other item that is commonly used in 
business I will use that term instead of business object.  I want a 
system that is simple to implement.

And sure, anybody can learn anything.  That does not mean they will, 
or that there is not a better way.  Relational systems have been 
around for a long time.  None have been implemented in a way that is 
useful to small/medium businesses without a lot of technical 
assistance (read that to mean modification complexity and maintenance 
for adapting the system for the best strategic benefit to the 
business organization as it changes over time) (unless of course, 
they are not flexible, aka Quickbooks, MYOB etc which are probably 
not relational anyway and certainly not modifiable.)

After having been paid to implement 50 to 80% of the same thing over 
and over again there has to be a better way.  This common element 
could be built into the abstraction layer because it can be reused. 
I believe there should be a way to express this common stuff in a way 
that more non-technical users can have access to it.  This also makes 
it easier to use for technical folks.  I will continue to push in 
this direction, for a system that hides the complexity and is easy to 
use and understand.  If that is not the direction of GNUe, please let 
me know and I will shut up.

It would have helped a lot more if you would have explained what 
direction you see the abstraction going and how it will be presented 
to the user since that was the point to my emails.

neilt
address@hidden