«

http://martinfowler.com/bliki/OrmHate.html

Given some of the threads we've had...

AHS
--
Never interrupt your enemy when he is making a mistake.
--Napoleon

Arved Sandstrom wrote:
> http://martinfowler.com/bliki/OrmHate.html
>
> Given some of the threads we've had...

Bookmarked.

This article succinctly explains points I've struggled to make over the years.
It gives an excellent description of the "impedance mismatch" between the
object and relational world views.

Now if all programmers who deal with object-to-relational mapping would
only read it.

Thanks for bringing it to our attention.

--
Lew

On Thu, 10 May 2012 19:50:54 -0300, Arved Sandstrom
<> wrote, quoted or indirectly quoted
someone who said :

>http://martinfowler.com/bliki/OrmHate.html
>
>Given some of the threads we've had...

Object/Relational mapping = ORM

We are very close to the point for many problems when you can store
your entire database in RAM or Flash RAM. It would seem to me, that
should spawn a new set of tools for managing data that don't have to
worry about fine tuning access times.

I also think there should be a database that deals with Java objects,
that lets you iterate using ordinary java for : each loops. If the
whole thing were designed with a Java API in mind, surely it should be
able to do more that SQL with much less futzing.
--
Roedy Green Canadian Mind Products
http://mindprod.com
Programmers love to create simplified replacements for HTML.
They forget that the simplest language is the one you
already know. They also forget that their simple little
markup language will bit by bit become even more convoluted
and complicated than HTML because of the unplanned way it grows.
..

On 5/10/2012 6:50 PM, Arved Sandstrom wrote:
> http://martinfowler.com/bliki/OrmHate.html
>
> Given some of the threads we've had...

What he says is certainly good, but I am not sure
that it is all new.

Using an ORM does make all problem disappear. But that
is just a special case of: using tool X does not make
all problem disappear. But making some problems
disappear is still good.

Arne

On 5/10/2012 7:52 PM, Roedy Green wrote:
> On Thu, 10 May 2012 19:50:54 -0300, Arved Sandstrom
> <> wrote, quoted or indirectly quoted
> someone who said :
>> http://martinfowler.com/bliki/OrmHate.html
>>
>> Given some of the threads we've had...
>
> Object/Relational mapping = ORM

Well - everybody knows that.

> We are very close to the point for many problems when you can store
> your entire database in RAM or Flash RAM. It would seem to me, that
> should spawn a new set of tools for managing data that don't have to
> worry about fine tuning access times.

Persistence to disk is not just done because RAM is more expensive
than disk. People like to have their data after a power failure.

Flash RAM is disk not memory.

> I also think there should be a database that deals with Java objects,

It is called an OODBMS.

And if you had read the article you would know how they did not succeed.

Arne

On 5/10/12 5:03 PM, Arne Vajhøj wrote:
> On 5/10/2012 6:50 PM, Arved Sandstrom wrote:
>> http://martinfowler.com/bliki/OrmHate.html
>>
>> Given some of the threads we've had...
>
> What he says is certainly good, but I am not sure
> that it is all new.
>
> Using an ORM does [not] make all problem disappear. But that
> is just a special case of: using tool X does not make
> all problem disappear. But making some problems
> disappear is still good.
>
> Arne
>
>
I added the missing "not" you clearly meant to have in there

On 5/10/2012 9:40 PM, Daniel Pitts wrote:
> On 5/10/12 5:03 PM, Arne Vajhøj wrote:
>> On 5/10/2012 6:50 PM, Arved Sandstrom wrote:
>>> http://martinfowler.com/bliki/OrmHate.html
>>>
>>> Given some of the threads we've had...
>>
>> What he says is certainly good, but I am not sure
>> that it is all new.
>>
>> Using an ORM does [not] make all problem disappear. But that
>> is just a special case of: using tool X does not make
>> all problem disappear. But making some problems
>> disappear is still good.

> I added the missing "not" you clearly meant to have in there

Thanks.



Arne

On 5/10/2012 3:50 PM, Arved Sandstrom wrote:
> http://martinfowler.com/bliki/OrmHate.html
>
> Given some of the threads we've had...


Good find, thanks for reposting the link here. It seems to give a
brief, pithy overview of ORM as it exists today.

I might say a bit more after I've had a chance to digest it more.

Roedy Green schrieb:
> On Thu, 10 May 2012 19:50:54 -0300, Arved Sandstrom
> <> wrote, quoted or indirectly quoted
> someone who said :
>
>> http://martinfowler.com/bliki/OrmHate.html
>>
>> Given some of the threads we've had...
>
> Object/Relational mapping = ORM
>
> We are very close to the point for many problems when you can store
> your entire database in RAM or Flash RAM. It would seem to me, that
> should spawn a new set of tools for managing data that don't have to
> worry about fine tuning access times.
>
> I also think there should be a database that deals with Java objects,
> that lets you iterate using ordinary java for : each loops. If the
> whole thing were designed with a Java API in mind, surely it should be
> able to do more that SQL with much less futzing.

You got the Collection classes in Java. You can
more or less map an SQL query on that if you have
your objects in the memory.

But what this doesn't buy you are indexes, respectively
automatic indexing as databases do nowadays. It is
very tediuous to manually have indexes and also doesn't
make your domain model easily extensible.

I have worked on a solution for an interpreted language
and came up with an automatic indexing scheme.
Initially it did only speed up the access. Recently
I have also worked out relative quick updates on the
data (*). Problem is a little bit to not throw away the
indexes too quickly. And having logical cursor like
access is also challenging.

I also went for a custom implementation of some of
the Collection classes, to have the algorithms not
use iterators, but inline loops for speed. Isn't
possible with the existing classes since one cannot
access the fields. Also the custom classes automatically
shrink the indexes, what the normal Collection classes
don't do.

Overall implementation size of the indexer:
- 9 Classes

I think indexes, or what has often been called access
paths, in one way or the other are always key to
databases. The problem carries over to memory
based solutions. But one can do with a library
of only a few classes for memory.

Bye

(*)
https://plus.google.com/u/0/b/103259...ts/FtcxQBCudjU

Jan Burse schrieb:
>
> Overall implementation size of the indexer:
> - 9 Classes

Maybe there are other, especially public, libraries
around. Didn't research yet, since I wasn't sure
about the specs until recently.

Bye