"Tim Bates" <tim / bates.id.au> schrieb im Newsbeitrag
news:20040107100517.GA7464 / bates.id.au...
[snip persistent storage selection]
> The other way my options can be divided is (and I'm simplifying things a
> bit again) between those libraries that present the data as objects and
> those that present it as database rows. Let me clarify:
>
> #<Person:0x40132728 @name="name", @number="phone number",
@address="address">
>   vs
> ["name","address","phone number"]
>
> I like the first one better, because you get encapsulation and behaviour
> with your data, but most of the database interface libraries that I've
> seen of that type tend to take most of the querying out of the hands of
> the user. They allow you to retrieve objects that have properties that
> match a given example, but very seldom any more complex than that - the
> equivalent of limiting yourself to "SELECT * FROM table WHERE
> table.column = ?" type queries only. Part of the reason I like RDBMSs is
> that I can do complex queries which don't necessarily return a simple
> list of objects, like:
>
> "SELECT s.name AS name, COUNT(DISTINCT t.customer_id) AS customers
>  FROM salesperson s JOIN transactions t ON s.id = t.salesperson
>  ORDER BY customers DESC;"
>
> This really returns a salesperson-to-integer mapping of how many
> customers a salesperson has dealt with. You can't represent this as a
> plain list of objects, unless you created a special type of object just
> for it (which is silly) and most OO-type database libraries won't let
> you make that sort of query at all without going behind their backs,
> which is really ugly.

There are however object relational mapping tools that come with their own
query language.  These query languages are most likely not as powerful and
flexible as SQL but they ten to be more flexible than QBE (query by
example), which you mention.

> The alternative is to use something like vanilla DBI, in which you write
> your own SQL and everything comes back as arrays of values. This allows
> you to do whatever queries you want but you lose the niceness of the OO
> approach. I don't want to do vanilla DBI, it's too messy.
>
> What I want is some sort of happy medium, and I'm starting to think I'll
> have to write it as none of the database interface libraries I've
> evaluated do it the way I want - which is the motivation for writing a
> lot of software, is it not? I believe that's how Ruby itself got its
> start, so I'm in noble company...
>
> But also on a deadline. Any suggestions?

You didn't say whether your project has Ruby as a requirement written on
it or whether tools you use must be free.  In case not, you could consider
object relational binding tools like

 - Lafcadio (Ruby, free)
   http://rubyforge.org/projects/lafcadio/

 - Apache OJB (Java, free)
   http://db.apache.org/ojb/

 - JDO implementations (Java, not all free, comes with it's own query
language)
   http://java.sun.com/products/jdo/
   http://jdocentral.com/

etc.


Or you consider an OO database and write only the query language parser
yourself.  You could then use

 - db4o (Java, commercial with reasonable pricing) with SODA query
language
   http://www.db4o.com/
   http://www.odbms.org/soda/

etc.

You'll probably notice that I'm coming from a Java background. :-)  I'm
sure there are similar tools for other languages.

Kind regards

    robert