gnue-dev
[Top][All Lists]
Advanced

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

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


From: Leandro Guimarães Faria Corsetti Dutra
Subject: Re: [Gnue-dev] Object-Relational Mapping?
Date: 23 Jan 2003 10:42:08 +0100

On Sat, 2003-01-18 at 13:38, neilt wrote: 
> 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.

        I fail to see how OO would be easier than SQL, nor even as easy (or as
less difficult, as you wish).

        OO is a natural only for simulation, user interface and such
programming tasks.  For data manipulation, it creates additional
complexity and therefore reduces both ease of use and power.


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

        Not actually, only a basic understanding of Set Theory and Predicate
Logic.  These are not rocket science, nor exclusivity of CS.


> 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.

        His fault, but his IT staff, and even business analysts, should be able
to teach him how to do simple QBE or even relational queries if he needs
to.

        Or are you hinting that the CEO of a company will decide on technology
based not on its excellence but on mindshare, and that IT should sheeply
comply?  Generally that is true no matter of what IT says, but I fail to
see why a free software project should dumb down.

        But if you want something for the CEO or Controller, I recommend _What,
Not How_ by CJ Date.


> 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.

        AFAICS, this is user interface and programming, not DBMS domain.  But
even when mapping user interface and programming to the DBMS, the
relational model and even its corruption, SQL, are much more natural,
generic and powerful than an OO data back-end.


-- 
 _
/ \ Leandro Guimarães Faria Corsetti Dutra        +41 (21) 216 15 93
\ / http://tutoriald.sf.net./                 fax +41 (21) 216 19 04
 X  Orange Communications CH                      +41 (78) 787 15 93
/ \ Campanha da fita ASCII contra mensagens HTML  +41 (21) 648 11 34





reply via email to

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