From: has <has.temp3@...>
Date: 2007-03-21T10:50:07+09:00
Subject: Re: Object/Relational Mapping is the Vietnam of Computer Science

On 20 Mar, 19:17, Gary Wright <gwtm...@mac.com> wrote:
> What would a Ruby interface to the underlying database engine (indexed
> tables) look like?  [...]  Is
> the impedance mismatch between Ruby (or any other OO language) and
> Codd's relational algebra too great to cross smoothly?

IANADBA, but FWIW, here's one idea for dealing with the O-R impedance
mismatch: model the queries, not the tables.

i.e. Create an API that makes it easy to perform relational database
operations from an OO language, rather than trying to make a bunch of
square data structures look like a big triangular one. Instead of
writing a code generator that churns out custom classes to represent a
database's tables, and then trying to shoehorn useful behaviours into
that, define a set of standard classes and methods that represent the
various database elements - table, query, result set, etc. - and the
operations you'd perform on them - join, select, dump, etc. This might
give users a basic syntax like:

d = database('My DB')
t = d.table(:foo) + d.table(:bar)
q = t[field(:size) > 100]
r = q.get(:name, :color)
r.each { |name, color| puts "#{name} likes #{color}" }

which could optionally be dressed up with a bit of db-specific
syntactic sugar if desired, allowing users to write more concise
expressions such as 'd.foo + d.bar', 't[it.size > 100]', etc.

It's an approach I used a couple years back when writing an Apple
event bridge for Python. (Apple event-based IPC is an unusual mix of
RPC and simple first-class queries with hybrid relational+object
semantics.) While the resulting API may feel a little less OO-like
than other Python-AE bridges that tried to put a strictly OO face on
everything, its query-centric design made it significantly easier to
expose the full range of AE functionality and created fewer hidden
gotchas and compatibility problems. Admittedly, the full relational
database model is a bit more complicated than the Apple Event Object
Model, but given the issues with the traditional ORM approach, a query-
centric approach could be worth a look.

has
--
http://appscript.sourceforge.net
http://rb-appscript.rubyforge.org
http://appscript.sourceforge.net/objc-appscript.html