From: Jochen Theodorou <blackdrag@...>
Date: 2007-03-30T14:25:04+09:00
Subject: Re: Object/Relational Mapping is the Vietnam of Computer Sci

Austin Ziegler schrieb:
> On 3/29/07, Jochen Theodorou <blackdrag@uni.de> wrote:
>>> Like I said, "model" is a vague word. When you say "relational
>>> model", the *meaning* is the "Relational Model of Data" (e.g., the
>>> theory). At this point, there's nothing related for an "Object Model
>>> of Data".
>> but the relational algebra is about queries not data in the first
>> place.
> 
> The Relational Model of Data is about how to organise the data in such a
> way that relational algebra is able to work. So your statement isn't
> really correct. Relational algebra doesn't work without the organisation
> of the data into sets of tuples and attributes.

very right, it is not only the data, it is its organization and the 
relations between them too. Might be that data is king, but only after 
it is transformed with respect to the relational model.

>>> When one says "object model", one usually means "the hierarchy or
>>> graph of objects that I am using to represent the data and operations
>>> in my implementation." In relational terms, that is a schema.
>> the operations are part of the schema?
> 
> Are you not understanding what I'm saying? I'm making an analogy here,
> not a direct correspondence.

then why did you mention the operations at all?

> What people call an "object model" is similar to a relational schema. 

ah, well I used the term different. I used it in the term of... how 
objects are related, behave and what operations can be done with them.

[...]
>>> but I consider encapsulation probably the defining feature of OO
>>> (even more than inheritance, because there are strong arguments for
>>> composition instead).
>> encapsulation in terms of grouping data together? hat is not more a
>> definition as a table is.
> 
> I can't parse this; encapsulation is, as I understand it, combining data
> and operations.

that's how OO defines encapsulation, that is not how encapsulation 
defines OO. At last that is my view on this.

[...]
>>> Just the opposite. An object model is closely related to a data model
>>> (or a database schema, if you prefer).  There's no overarching theory
>>> of object modelling (at least not yet, as Ed pointed out), whereas
>>> there *is* an overarching theory of data and relations.
>> data *and* relations, yes. A theory about data only would be useless,
>> or not?
> 
> This is basic relational theory; please read more on it.

that misses the point. I wanted to say, if you look at the OO world 
without the same relations you use in the relational world, then what is 
it worth? I mean if you take an object and rip off the methods, what is 
left then? A mere data holder, a abstract type. Or not?

>>>>> Just because one *can* create something that works without a
>>>>> mathematical theory behind it does not mean that one *should* do so.
>>>> or should not do so.
>>> Fair enough, but if one chooses to step away from something that has
>>> theoretical underpinnings, one should at least be prepared to make a
>>> coherent explanation as to why it's better.
>> coherent? "My tests are showing my application is faster with it" or "I
>> am faster in prototyping" is for some cases coherent enough.
> 
> Not at all. Performance is about implementations, not about concepts.

If something proves to be better for a certain situation in a pragmatic 
way, then I should really consider to use that.

[...]
> OO database vendors *as a class* make specious claims,

"as a class"... a class without instances?  A singleton then maybe. 
Maybe even a non existing. Sorry, I am no friend of putting a vague 
group people together and claiming that they are doing something bad.

[...]
>>>> ok, see "A Query Algebra for Object-Oriented Databases (1989)" on
>>>> citeseer http://citeseer.ist.psu.edu/shaw89query.html
>>> I skimmed through this; reading it, it's an attempt to *return* some
>>> level of relational algebra to object databases ... all the way back
>>> in 1989.
>> please read it again. there is no such thing as "returning" there is
>> only a thing of mapping one concept to another. Something like a
>> morphism.
> 
> No, it's "returning."

that's no base for discussion. returning or not does not matter.

> I read it thoroughly enough to see that they were
> trying to add some level of relational algebra *back* to object
> databases because what was happening in object databases was simply not
> good enough.

your view.

> The authors weren't quite clear enough on the concepts (despite having
> clearly read C.J. Date, as referenced in the paper) to admit this,
> though.

what concepts? You are not very clear yourself. Basically you are saying 
they have not understood the relational model and OO altogether. I guess 
they are also of your class of OO database vendors.

>>> Sadly, the authors still think that first normal form is an
>>> unnecessary restriction on the logical formation of the data -- and
>>> they have to synthesize first normal form tuples to obtain relational
>>> algebra capabilities in object databases.
>> where?
>>
>> I have read: "One research direction in the modeling of
>> object-oriented is the extension of the relational model to build
>> complex types. Early extensions relaxed the first normal form
>> requirement of the relational model to allow set valued attributes.
> 
> They don't condemn this; first normal form is something that really
> makes a lot of sense in data and object modelling. They have to
> *synthesize* a first-normal form for their relational algebra to even
> *work*!

extend is not really synthesize. And what exactly is so bad about that? 
It is a common thing in mathematics.

>>> I haven't looked further, but it's not quite a positive refutation of
>>> my statement.
>> you claimed there is no algebra, I proved you wrong. I myself said
>> there is much space for nonsense and that without constraints there
>> will never be a "solution". So either we talk about such constraints
>> or we end the topic. It makes no use to give more and more new papers
>> just that you can say that you don't like the opinion of the author."
>>
>> I guess you mean a different part?
> 
> They added relational algebra to an object database model by
> synthesizing a tuple for relational operations. That's an utter failure
> to provide an object algebra.

why? A detailed explanation please.

> Read the paper again: they *clearly* say
> they synthesize tuples to layer relational algebra on top of object
> databases.
 >
> It's not a matter of disagreeing with the authors, it's a matter of
> recognising that the paper doesn't really do what you think it does.

and what do you think that I think it does? That I can't use the 
relational algebra as it is for an object algebra was clear from the 
beginning. But that is not important here. The important thing is how a 
modification I make affects the system as a whole. If it does not 
violate other mathematic axioms then it is normally a valid model.

>>>>> Sure, an object store can be set up to allow for smart loading and
>>>>> such, but that *doesn't* mean that it's a good idea. It might be
>>>>> the "right now" idea, but it is something you'll have to pay the
>>>>> piper for using at some point in the future.
>>>> depends on my goals, or not?
>>> I've said as much. Right now solutions usually meet one's immediate
>>> goals, but rarely meet long-term goals and often result in increased
>>> costs in the long-term.
>> might be true, but if your boss says that he needs to save money in
>> the short term it is a different thing. For example for prototypes,
>> for example for small applications, for example for applications that
>> don't share data, for example for applications without the need to do
>> reporting.
> 
> All of these will benefit more from relational databases than object
> databases.

In what way? Don't come with "in the long term", mantras don't make up 
for reasons.

> If they're *that* small, just use a plain-old object store
> (like PStore or Madeleine, if you must);

small in lines of code possibly yes, that does not mean it does not have 
to query or has to handle data bigger than the available memory

> don't bother with an object database 

what bother? Depends on the database, or not?

> -- because you'll spend almost as much time in the short term,
> and much more time in the long term, with that as you would with a good
> ORM and a good SQL database.

at the moment I can't say that this is true. Maybe the solutions of ORM 
are quite good, but if you take a look in the Java world.. I really 
prefer db4o over Hibernate+HSQLDB or even postgres/mysql/oracle/xy if my 
application is "small".

bye blackdrag