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+Of+Computer 
> +Science.aspx
> http://www.odbms.org/download/031.01%20Neward%20The%20Vietnam%20of% 
> 20Computer%20Science%20June%202006.PDF
> (pdf from odbms.org)
> Disclaimer: I am unaffiliated with Ted Neward, db4o, odbms.org,  
> etc. etc.
>