From: John Joyce <dangerwillrobinsondanger@...>
Date: 2007-03-21T11:10:33+09:00
Subject: Re: Object/Relational Mapping is the Vietnam of Computer Science

Well, perhaps it is object orientation for object orientation's sake?
Sometimes a program doesn't need objects either.
Functional, procedural programming is sometimes the way to go.
OOP helps organize code and reuse features, as well as protect data.
But inside, even OOP is really procedural stuff that is just highly  
organized.
At some level it is still procedural, to the machine.

On Mar 21, 2007, at 10:50 AM, has wrote:

> 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
>
>