Re: Object/Relational Mapping is the Vietnam of Computer Science

On 20 Mar, 19:17, Gary Wright <gwtm...@xxxxxxx> 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

.

Relevant Pages

  • Re: Three Kinds of Logical Trees
    ... that includes all code that uses the dbms api would have all such units ... a variable of type int, with an int value and invoke a method ... ... >> database would have all the data and functions it needs to address ... I have no plans to design a language, but I'm happy to learn anyway ...
    (comp.databases.theory)
  • Re: Darkroom software Help
    ... Apple's computer operating system OS-X includes the Java ... programing language, compiler, and integration software. ... have an Apple this fall. ... Said that, my system is based on a commercial lab interface, the ...
    (rec.photo.darkroom)
  • Re: Another idea from pick goes mainstream...
    ... A relational database has nothing to do ... SQL is one of the ... is now considered THE language for any dbms implementing the relational ... Then, XML came out. ...
    (comp.databases.pick)
  • Re: If you were developing a database in Forth...
    ... database that worked well, and then Dennis Ruffer provided source code ... to do the same thing in some other language and it failed it was ... It doesn't matter if the project was a stunning success or a ... that failure was the language we invented. ...
    (comp.lang.forth)
  • Re: OO vs. RDB challenge
    ... >> loans have greater risk so not all users that can approve a loan ... >> database engine for that matter)? ... >> language for somethings, ah well. ... string group) ...
    (comp.object)