* David Binger wrote on [2007-09-11 16:46:05 -0400]:
> I'm curious about how writing a query is easier than writing a loop.
> It doesn't seem better to me.

Oftentimes writing a SQL query isn't any better, or much different,
than the average list comprehension.

Given either a table (or a list or mapping) of People and Roles (and
since a Person can have more than one role, a People-Role table for
the SQL folks), finding everyone who is a supervisor:

    SELECT p.first_name, p.last_name
    FROM   people p, role r, people_role pr
    WHERE  pr.people_id = p.id
      AND  pr.role_id   = r.id
      AND  r.name = 'supervisor'

Doesn't seem any easier than (you can imagine the classes):

    supervisors = [p for p in people where 'supervisor' in
    p.get_roles()]

Ok, I know that's not a fair comparison between SQL the language and
whatever 'language' I've exposed in the Person object. But if the
question is, which is easier to type in at the command prompt, I'm
very happy with the Durus prompt thanks!

Perhaps for the 5 minute talk whoever is doing it could be sure to
point out something that is difficult in SQL but trivial with an
object database.

There are some times when writing a SQL query is a lot *harder*
(think hierarchical queries) than the equivalent traversal of
objects. Some example of that difference, if it can be worked into a
screen cast, might be useful in opening eyes.

I used to have to deal with a deeply nested hierarchy for a records
management solution and it was painful writing SQL queries for it.
In the end we cheated by storing the hierarchy in a second, mangled,
'key'. But it was still painful. Various SQL engines have varying
(or not at all) levels of support for doing hierarchical queries -
but such facilities are not part of any SQL standard at all.

The same functionality would have been trivial to implement with a
Python representation and 'query'.

I wonder if ORMs such as SQLAlchemy have an easy to use mechanism to
traverse (up or down) or retrieve all of a hierarchy? Something like:

    root/
        forms/
            insurance/
                medical/
                  form-101
                  posthumous/
                    form-999
                dental/
                  form-1832
                  form-1920
                animal/
                property/
                  form-hurricane-x
            hr/
        sales/

Fairly easy to represent in Python; significantly harder to do in ANSI SQL.