[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Object/Relational Mapping is the Vietnam of Computer Science

Demetrius Gallitzin

3/20/2007 3:30:00 PM

I have searched around, but I very rarely find any mention of Ruby
with OO databases. YAML might work as a database, but I am hoping for
something more like db4o.com's GPL database engine.

Does anyone attempt Ruby with something like db4o.com's oo database engine?

I personally think that relational storage is evil. It was built in a
time where computers were much slower and much dumber, but we have not
gotten any smarter. For transactional databases, it attempted to
optimize speed and CRUD functions. For datawarehousing and business
intelligence, relational databaes serve no purpose. Has anyone dealt
with relational star and constellation schemas for datawarehouses? An
oo structure would suit business intelligence software much better.
Ruby on Rails only masks an underlying problem.

Reference that inspired the subject's title:
http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Sc...
http://www.odbms.org/download/031.01%20Neward%20The%20Vietnam%20of%20Computer%20Science%20June%...
(pdf from odbms.org)
Disclaimer: I am unaffiliated with Ted Neward, db4o, odbms.org, etc. etc.
176 Answers

John Joyce

3/20/2007 4:56:00 PM

0

You could describe ORM as masking a problem or you could call it
interfacing smartly.
The problem with OO databases is that they're notoriously difficult
to create and use. Perhaps not so much when only one process uses it,
but quite a mess when you have many queries.
I would argue that part of the problem is SQL being very unlike any
non-database programming language. Building a database from the
ground up, in an OOP language like Ruby is a fascinating idea but not
for the squeamish or subgenius. Perhaps one of Matsumoto-san's
coworkers, or Mr. DeNatale (a big Smalltalker) could address the
concept better.

On Mar 21, 2007, at 12:29 AM, Demetrius Gallitzin wrote:

> I have searched around, but I very rarely find any mention of Ruby
> with OO databases. YAML might work as a database, but I am hoping for
> something more like db4o.com's GPL database engine.
>
> Does anyone attempt Ruby with something like db4o.com's oo database
> engine?
>
> I personally think that relational storage is evil. It was built in a
> time where computers were much slower and much dumber, but we have not
> gotten any smarter. For transactional databases, it attempted to
> optimize speed and CRUD functions. For datawarehousing and business
> intelligence, relational databaes serve no purpose. Has anyone dealt
> with relational star and constellation schemas for datawarehouses? An
> oo structure would suit business intelligence software much better.
> Ruby on Rails only masks an underlying problem.
>
> Reference that inspired the subject's title:
> http://blogs.tedneward.com/2006/06/26/The+Vietnam+O...
> +Science.aspx
> http://www.odbms.org/download/031.01%20Neward%20The%20Vie...
> 20Computer%20Science%20June%202006.PDF
> (pdf from odbms.org)
> Disclaimer: I am unaffiliated with Ted Neward, db4o, odbms.org,
> etc. etc.
>

Austin Ziegler

3/20/2007 5:47:00 PM

0

On 3/20/07, Demetrius Gallitzin <gallitzin@gmail.com> wrote:
> I have searched around, but I very rarely find any mention of Ruby
> with OO databases. YAML might work as a database, but I am hoping for
> something more like db4o.com's GPL database engine.

That's usually because OO databases aren't worth the code they're
written in for most purposes. I've written about this extensively and
recently; I suggest you search for it.

> Does anyone attempt Ruby with something like db4o.com's oo database
> engine?

Someone probably has, although it's likely a waste of time.

> I personally think that relational storage is evil.

Then you're either ignorant or a fool. I hope it's just the former,
because ignorance can be removed with proper education. Relational
databases are a more natural and flexible way of storing data that has
value beyond a single program than any hierarchical database will ever
be (and both OO and XML databases are hierarchical databases, make no
mistake about it!).

Object databases are fixed to a single representation of data; in
reality, there are many ways to view data and so a far more flexible
storage format is useful and necessary. Only people who don't understand
data modelling (and *as such* also don't understand object modelling)
would dismiss everything that Codd taught about data, relations, and
relational algebra (set theory, basically), no matter how badly the
current crop of SQL databases actually implement what he outlined.

> It was built in a time where computers were much slower and much
> dumber, but we have not gotten any smarter.

You're incorrect on both your history and your assessment.

> For transactional databases, it attempted to optimize speed and CRUD
> functions.

Again, this is incorrect. Relational algera are about set operations on
data. SQL models this badly, but it allows for better data combination
than any single OO model will ever allow.

> For datawarehousing and business intelligence, relational databaes
> serve no purpose. Has anyone dealt with relational star and
> constellation schemas for datawarehouses? An oo structure would suit
> business intelligence software much better.

This is completely incorrect. A single given application or query may
work better with a particular object model, but the whole set of
applications that may run on databases are far better served by flexible
models. If I can only access orders through customers, then I have
exponentially increased the amount of work I must perform to find out
which customers have ordered a particular line item.

> Ruby on Rails only masks an underlying problem.

This is correct, but only to the extent that Rails protects people from
proper data modelling experience. Integration databases (cf Fowler) may
be out of favour in Rails (in favour of application databases) but that
doesn't mean that an application database may not be used in an
integration fashion in the future as people find it necessary to do
analysis on what is in the application database.

> Reference that inspired the subject's title:
> http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Sc...

I don't see any value in this article at all, having worked in the real
world with such problems. The solution is to have something that parses
your DDL or database structure and generates your statically typed
language, or work with a smarter language, like Ruby and a smart ORM
mapper if you want automatic mapping (such as ActiveRecord or Og).
Sometimes, you don't and a custom approach is better.

An OO database is almost never the answer to anything. An XML database
is even less likely to be an answer.

-austin
--
Austin Ziegler * halostatue@gmail.com * http://www.halo...
* austin@halostatue.ca * http://www.halo...feed/
* austin@zieglers.ca

Demetrius Gallitzin

3/20/2007 6:17:00 PM

0

I am interested in several things.

1) Enterprise integration. Trying to put two relational database
applications together costs as much effort as building one relational
database application. This falls under the work of William McCarthy
(Ph.D.), REA modeling, and Pavel Hruby (Ph.D) pattern-based enterprise
structures {now sold to Microsoft}. Putting data into normalized form
seems to put things into unique patterns that are painful to integrate
(with someone else's project). I look at two ERD diagrams for two
applications, and then I'm told to make them work nicely together.

2) Business Analysis (OLAP and Data Mining) -- Decision support is
interested in analyzing rather than processing data. Normalized data,
to me, seems all about processing data. As the purpose of data
analysis is to examine and uncover the redundancies in data, the
uniqueness constraints placed on the relational model by the
normalization process are not desirable for decision support (Roiger
and Michael Geatz, _Data Mining: A Tutorial-Based Primer_ 2003, page
182). To me, it means that transaction databases in normalized form
aren't structured well for OLAP or Data Mining type functions.

When you have business models and you're forced to think in terms of
Codd's normalized form, it seems to kill the agile environment. I
think in business terms, and then have to restructure the data into
something foreign to the business....and a layer of maintainability
and complexity above the business itself?

Even if OO databases are flawed, I'd rather be able to think OO, store
OO, and model things as OO. Yeah, maybe a Smalltalk guy can help. :)

On 3/21/07, Austin Ziegler <halostatue@gmail.com> wrote:
> On 3/20/07, Demetrius Gallitzin <gallitzin@gmail.com> wrote:
> > I have searched around, but I very rarely find any mention of Ruby
> > with OO databases. YAML might work as a database, but I am hoping for
> > something more like db4o.com's GPL database engine.
>
> That's usually because OO databases aren't worth the code they're
> written in for most purposes. I've written about this extensively and
> recently; I suggest you search for it.
>
> > Does anyone attempt Ruby with something like db4o.com's oo database
> > engine?
>
> Someone probably has, although it's likely a waste of time.
>
> > I personally think that relational storage is evil.
>
> Then you're either ignorant or a fool. I hope it's just the former,
> because ignorance can be removed with proper education. Relational
> databases are a more natural and flexible way of storing data that has
> value beyond a single program than any hierarchical database will ever
> be (and both OO and XML databases are hierarchical databases, make no
> mistake about it!).
>
> Object databases are fixed to a single representation of data; in
> reality, there are many ways to view data and so a far more flexible
> storage format is useful and necessary. Only people who don't understand
> data modelling (and *as such* also don't understand object modelling)
> would dismiss everything that Codd taught about data, relations, and
> relational algebra (set theory, basically), no matter how badly the
> current crop of SQL databases actually implement what he outlined.
>
> > It was built in a time where computers were much slower and much
> > dumber, but we have not gotten any smarter.
>
> You're incorrect on both your history and your assessment.
>
> > For transactional databases, it attempted to optimize speed and CRUD
> > functions.
>
> Again, this is incorrect. Relational algera are about set operations on
> data. SQL models this badly, but it allows for better data combination
> than any single OO model will ever allow.
>
> > For datawarehousing and business intelligence, relational databaes
> > serve no purpose. Has anyone dealt with relational star and
> > constellation schemas for datawarehouses? An oo structure would suit
> > business intelligence software much better.
>
> This is completely incorrect. A single given application or query may
> work better with a particular object model, but the whole set of
> applications that may run on databases are far better served by flexible
> models. If I can only access orders through customers, then I have
> exponentially increased the amount of work I must perform to find out
> which customers have ordered a particular line item.
>
> > Ruby on Rails only masks an underlying problem.
>
> This is correct, but only to the extent that Rails protects people from
> proper data modelling experience. Integration databases (cf Fowler) may
> be out of favour in Rails (in favour of application databases) but that
> doesn't mean that an application database may not be used in an
> integration fashion in the future as people find it necessary to do
> analysis on what is in the application database.
>
> > Reference that inspired the subject's title:
> > http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Sc...
>
> I don't see any value in this article at all, having worked in the real
> world with such problems. The solution is to have something that parses
> your DDL or database structure and generates your statically typed
> language, or work with a smarter language, like Ruby and a smart ORM
> mapper if you want automatic mapping (such as ActiveRecord or Og).
> Sometimes, you don't and a custom approach is better.
>
> An OO database is almost never the answer to anything. An XML database
> is even less likely to be an answer.
>
> -austin
> --
> Austin Ziegler * halostatue@gmail.com * http://www.halo...
> * austin@halostatue.ca * http://www.halo...feed/
> * austin@zieglers.ca
>
>

dave rose

3/20/2007 6:20:00 PM

0

has anybody used CACHE with ruby... it the best of both worlds and
knocks the pants
in performance off most relationals and it's reliable.... i am really
curious...
is it USA thing (against OO databases) because European Trade Schools
CACHE is required learning... i've bought the only English translated
text book
authored by all German Professors... OO db design has to be in the
database for better design thoroughness just as it accepted elsewhere in
computer science. To topdown OO unit test the whole system and not just
the ruby front end is better and more consisent....


--
Posted via http://www.ruby-....

brabuhr

3/20/2007 6:23:00 PM

0

On 3/20/07, Austin Ziegler <halostatue@gmail.com> wrote:
> That's usually because OO databases aren't worth the code they're
> written in for most purposes. I've written about this extensively and
> recently; I suggest you search for it.
>
> > I personally think that relational storage is evil.
>
> Then you're either ignorant or a fool. I hope it's just the former,
> because ignorance can be removed with proper education. Relational
> databases are a more natural and flexible way of storing data that has
> value beyond a single program than any hierarchical database will ever
> be (and both OO and XML databases are hierarchical databases, make no
> mistake about it!).

Anyone have any comments / experience with "associative" databases like:
http://www.associativesolutions.com/rel...
http://www.lazysoft.com/technology_sen...

Austin Ziegler

3/20/2007 6:37:00 PM

0

On 3/20/07, Demetrius Gallitzin <gallitzin@gmail.com> wrote:
> 1) Enterprise integration. Trying to put two relational database
> applications together costs as much effort as building one relational
> database application. This falls under the work of William McCarthy
> (Ph.D.), REA modeling, and Pavel Hruby (Ph.D) pattern-based enterprise
> structures {now sold to Microsoft}. Putting data into normalized form
> seems to put things into unique patterns that are painful to integrate
> (with someone else's project). I look at two ERD diagrams for two
> applications, and then I'm told to make them work nicely together.

Then you're integrating them wrong. If you can't integrate two
databases, integrate two applications through application interfaces.
See the writings of Fowler and, to some degree, of DHH. Sometimes it's
useful to even take an approach where a "third" application is created
(single sign-on, for example). This is not something that is helped
*in the least* with OO databases. Repeat after me: OO databases aren't
a solution to anything but a single problem.

> 2) Business Analysis (OLAP and Data Mining) -- Decision support is
> interested in analyzing rather than processing data. Normalized data,
> to me, seems all about processing data. As the purpose of data
> analysis is to examine and uncover the redundancies in data, the
> uniqueness constraints placed on the relational model by the
> normalization process are not desirable for decision support (Roiger
> and Michael Geatz, _Data Mining: A Tutorial-Based Primer_ 2003, page
> 182). To me, it means that transaction databases in normalized form
> aren't structured well for OLAP or Data Mining type functions.

Again, your understanding is wrong. Normalized data is about data
representation. There's *nothing* wrong with the relational model for
decision support or business analysis. There may be problems with the
implementations of SQL databases, but set operations still apply to
business analysis -- and OO databases *still* hurt here because
they're only capable of asking a single question. DSS is all about
asking *lots* of questions in *lots* of different ways to uncover yet
other questions.

> When you have business models and you're forced to think in terms of
> Codd's normalized form, it seems to kill the agile environment. I
> think in business terms, and then have to restructure the data into
> something foreign to the business....and a layer of maintainability
> and complexity above the business itself?

I think that's a lack of imagination. When I was doing significant
database work, I also thought in business terms. The team that had the
problems with their database were the fools who thought that the
database could be modelled based on the object model. They didn't
think beyond their UI object model, which wasn't the *only* model
necessary in the application (it was a billing application).

> Even if OO databases are flawed, I'd rather be able to think OO, store
> OO, and model things as OO. Yeah, maybe a Smalltalk guy can help. :)

OO databases aren't flawed. They're disastrous.

-austin
--
Austin Ziegler * halostatue@gmail.com * http://www.halo...
* austin@halostatue.ca * http://www.halo...feed/
* austin@zieglers.ca

Austin Ziegler

3/20/2007 6:44:00 PM

0

On 3/20/07, brabuhr@gmail.com <brabuhr@gmail.com> wrote:
> On 3/20/07, Austin Ziegler <halostatue@gmail.com> wrote:
> > That's usually because OO databases aren't worth the code they're
> > written in for most purposes. I've written about this extensively and
> > recently; I suggest you search for it.
> >
> > > I personally think that relational storage is evil.
> >
> > Then you're either ignorant or a fool. I hope it's just the former,
> > because ignorance can be removed with proper education. Relational
> > databases are a more natural and flexible way of storing data that has
> > value beyond a single program than any hierarchical database will ever
> > be (and both OO and XML databases are hierarchical databases, make no
> > mistake about it!).
>
> Anyone have any comments / experience with "associative" databases like:
> http://www.associativesolutions.com/rel...
> http://www.lazysoft.com/technology_sen...

I'd never heard of these. The marketing speak sounds like hooey, and
Fabian Pascal quite agrees. Fabian Pascal is, if you will, the Richard
Dawkins of databases. He knows what the hell he's talking about, but
he's an abrasive man who often hurts his own points by his
abrasiveness. Here's three articles:

http://www.dbdebunk.com/page/page/...
http://www.dbdebunk.com/page/page/...
http://www.dbdebunk.com/page/page/3...

I suspect that these are to be heavily avoided in favour of properly
educating oneself about relational data models.

-austin
--
Austin Ziegler * halostatue@gmail.com * http://www.halo...
* austin@halostatue.ca * http://www.halo...feed/
* austin@zieglers.ca

Gary Wright

3/20/2007 7:18:00 PM

0


On Mar 20, 2007, at 1:47 PM, Austin Ziegler wrote:
> Again, this is incorrect. Relational algera are about set
> operations on
> data. SQL models this badly, but it allows for better data combination
> than any single OO model will ever allow.

Just some random thoughts I had while reading this thread...

I'm curious as to why query language development got hung up on SQL.
I've read a little bit about Tutorial D. Is SQL simply
another example of pre-mature standardization?

What would a Ruby interface to the underlying database engine (indexed
tables) look like? Could it get closer to Tutorial D by bypassing the
standard technique of 'marshaling' requests into SQL statements? Is
the impedance mismatch between Ruby (or any other OO language) and
Codd's relational algebra too great to cross smoothly?

Gary Wright

R. Mark Volkmann

3/20/2007 7:44:00 PM

0

On Mar 20, 2007, at 1:43 PM, Austin Ziegler wrote:

> He knows what the hell he's talking about, but
> he's an abrasive man who often hurts his own points by his
> abrasiveness.

Hmm ... this reminds me of somebody else (Austin) whose views I
usually agree with. ;-)

Trans

3/20/2007 8:17:00 PM

0



On Mar 20, 11:29 am, "Demetrius Gallitzin" <gallit...@gmail.com>
wrote:
> I have searched around, but I very rarely find any mention of Ruby
> with OO databases. YAML might work as a database, but I am hoping for
> something more like db4o.com's GPL database engine.
>
> Does anyone attempt Ruby with something like db4o.com's oo database engine?
>
> I personally think that relational storage is evil. It was built in a
> time where computers were much slower and much dumber, but we have not
> gotten any smarter. For transactional databases, it attempted to
> optimize speed and CRUD functions. For datawarehousing and business
> intelligence, relational databaes serve no purpose. Has anyone dealt
> with relational star and constellation schemas for datawarehouses? An
> oo structure would suit business intelligence software much better.
> Ruby on Rails only masks an underlying problem.
>
> Reference that inspired the subject's title:http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science...http://www.odbms.org/download/031.01%20Neward%20The%20Vietn......
> (pdf from odbms.org)
> Disclaimer: I am unaffiliated with Ted Neward, db4o, odbms.org, etc. etc.

If you're interested I have written a Ruby OODB which uses an RDBMS as
a storage back-end. It's called "Normal Ivy" or just "Norma" for
short. It's just a prototype, at this point, which I wrote to ensure
my idea would work. It does. But I haven't the time to polish it into
a solid project. Of course, it will never be as efficient as a
straight RDBMS, but it would certainly work well for many database
needs. And since it uses a relational database on the back-end, many
of Austin's criticisms can be countered through the use of VIEWS.

T.