Re: [Gnue-dev] Object-Relational Mapping?

[neilt]

At 1:41 PM +0100 1/17/03, Leandro Guimarães Faria Corsetti Dutra wrote:
>  > But whatever you call it, I think an abstraction above the relational
> >  database (or OODB) model is needed to make enterprise apps killer
> >  apps.
>
>         Why?

I am only talking about current implementations.  I should have been
more precise in my example.  Theory is excellent.  But customers use
implementations, implementors use (or should use)  theory.  The issue
I was trying to raise can be explained by taking your example
regarding views and walk through what a person has to know and do to
modify a view in the current batch of SQL servers (lets say add a
related table in IT terms or create a link to vendor products in
business terms.)

It is easy for an IT professional, but not for a non-it professional.
To make a killer app the complexity has to be removed.  Why do people
use Quicken.  It fits the buyers perception.  Extend that to the
buyer for an Enterprise App; the President or Chief Accountant for a
small to medium business.

Most of the stuff mentioned here requires a degree in Computer Science:

At 1:41 PM +0100 1/17/03, Leandro Guimarães Faria Corsetti Dutra wrote:
>         I would recomment reading http://www.thethirdmanifesto.com/ and
> http://dbdebunk.com./ and all mentioned literature, at least.

You will never get the President or Chief Account of a (non-software)
company to this level of understanding.

That is why a level of abstraction is required.  Purchase orders are
purchase orders.  There are general items that can be defined and
there are specific use items that need to be customizable for the
particular application or industry.  For example, a purchase order
will be issued to another business entity.  It will specify either
services or items to be purchased.  Of the items purchased some will
be consumable and some will be stocked.  It will also specify one or
many deliveries for the items purchased.  Etc.

In my experience, the business items (I would normally say objects to
business people) are 50 to 80% standard.  Customization occurs by
adding industry specific information to the item (object) and in how
the it is used.  "How it is used" is modified using security and
workflow.

The abstraction needs to make it easy to modify supplementary
information for each business object, security for the system (may be
business object level or higher), and modify workflow (including
approvals).  The abstraction is for the user or owner and also
benefits the implementor because he or she can bring applications
on-line faster without having to deal with all of the complexity.

I hope this explains my comments better.

Neil
address@hidden

At 1:41 PM +0100 1/17/03, Leandro Guimarães Faria Corsetti Dutra wrote:
> On Fri, 2003-01-17 at 00:34, Neil Tiffin wrote:
> >  I think the goal should be a simple to understand method of modifying
> >  the system behavior by non information systems professionals.
>
>         That is what the relational model was created for, see the original
> paper from Codd.  You can find that, and much more useful stuff, in
> http://dmoz.org./Computers/Software/Databases/Relational/.
>
>
> >  An
> >  object model (implemented well) is easy to explain to someone who is
> >  not up on the latest OODB vs relational issues.
>
>         Easy to explain, but very hard to unsderstand the details and operate.
>
>
> >  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.
>
>         Not true.
>
>         Normalisation is done at the logical level.  At the user schema level
> one can have updateable derived relations (views) that give users just
> what they need.  Optimisation, obviously, must be done at the physical
> level only.
>
>         Moreover, the very error messages the user is supposed to receive if
> updating a relation while violating any given constraint are not a
> hindrance, but a help for the user to understand the data he *needs* to
> know.
>
>         About the viability of this, see below.