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: 17 Jan 2003 13:41:44 +0100

        Having once criticised a GNUe conversation I spotted on an IRC log on
this subject, I was challenged to explain me better, and have since been
lingering without never taking the time to raise the issue.  Now that
you came by this by yourselves, I will throw in my 2c.


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.


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


> We need to deal with user customization at a higher level

        As far as data representation goes, there is nothing simpler than the
relational model.  Now if you are talking user interfaces, graphical
representations and the such, there is nothing blocking one of grafting
a GUI on a relational system.  That does away with OO complications,
which are always mingled with implementation details that in the
relational model are hidden at the physical and logical levels..


> Unfortunately, the ODMG standard does not (based on my 
> limited review) help in this area.  You really need to be technically 
> savvy to use it.

        That is not a failure by the ODMG standard, but an OO misfeature.  As
there is no such a thing as an OO data model, and as OO is not clear at
all even on basic issues: see Date and Darwen on The First and Second
Great Blunders, the confusion of class with relation and the question of
if an object is a value or a variable.

        Ultimately, OO data manipulation is a throwback to prerelational times,
and these gave us the infamous CODASYL of sad memory.


On Fri, 2003-01-17 at 08:23, Reinhard Mueller wrote:
> 
> Applications will probably not do die-hard normalization at any cost.

        Why not?  They certainly should.


> We
> believe that data of business applications is mostly of relational
> nature.

        This does not make sense.  The relational model certainly can represent
any data whatsoever.  This is a SQL failure, not a relational one.

        Now, if one wants to implement a valid D, that would be incredibly
nice, and even in scope (how can one build great apps withoug great DBs,
and how can great DBs be built without a true RDBMS?), but it is
certainly something to think about at least twice.

        I would recomment reading http://www.thethirdmanifesto.com/ and
http://dbdebunk.com./ and all mentioned literature, at least.


-- 
  _   Leandro Guimarães Faria Corsetti Dutra    +41 (21) 648 11 35
 / \                                            +41 (21) 216 15 93
 \ /  Lausanne, Vaud, Suisse                 fx +41 (21) 216 19 04
 / \  Fita ASCII contra correio eletrônico HTML             BRASIL





reply via email to

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