On 3/20/07, Demetrius G. [email protected] 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
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
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:
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.