Tim Bates <tim / bates.id.au> wrote:
> 
> 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.

What would you like it to return? Should it construct a class on the fly,
with fields 'name' and 'customers'? And should it use its own query
language to do so, or parse the sql query?

martin