gnue-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Neil Tiffin
Subject: Re: [Gnue-dev] Why the Object metaphor? (Was: Object-Relational Mapping?)
Date: Sat, 18 Jan 2003 21:04:02 -0500

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]