Re: A few comments about SchemeQL

[Noel Welsh <noelw@dai.ed.ac.uk>]

Oops, sent this to Francisco when I meant to send it to the list

Francisco Solsona writes:
>
> Yup, that's a good idea. Nevertheless, using native drivers or flat
> text *do* require a SrPersist-alike unit to provide a Scheme-level
> API, SchemeQL could then use. I'll try to document what exactly such a
> library should provide, and of course write a default one that will
> simply call SrPersist's procedures.

Agreed. If/when Scheme becomes popular, people will want to use
different drivers. DBI is one of the supposted advantages of using
Perl - the same DB interface to any database, including flat text.

> SchemeQL implements the "SQL Minimum Grammar", which any
> ODBC-compliant driver must support, and none of the above functions
> are part of that grammar.

> Of course, I can extend SchemeQL to support
> those functions, at the expense of needing the *driver* to support a
> broader range of database operations (SrPersist does, so no problems
> in the immediate future).

Ok, there's a tension between implementing what is cross-platform, and
what is useful. A database without intersections is virtually
useless. Without outer joins is useable (eg Postgres) but painful. I
think the fundamental set operations, interesection, union and
negation, are the basic operations one should have available in
SchemeQL.

It all depends on what see as SchemeQL's place in the scheme (no pun
intended) of things. As a basic system that will work everywhere, as a
usable system that fits most jobs, or as a hard-core system that does
everything. I think the middle option is the right one. Hard core DB
hackers are going to want to write SQL so they can access vendor
specific functionality, which will never find its way into SchemeQL,
and a basic system isn't much use for real work.

Agreed that a flat text system would have to support joins etc in the
driver to support this extended range of operations, but then if the
driver isn't supporting them, the programmer will have to code them to 
get anything useful done.

> You can find the latest version here:
> 
>         ftp://ftp.beta.fciencias.unam.mx/pub/solsona/schemeql

I'll have a look when I get a chance.

Shriram Krishnamurthi writes:
>
> Well, sure.  But the whole name of the game in databases is the
> trade-off between expressivity and efficiency.  First-class queries
> are mighty hard to optimize (though one of the most interesting recent 
> developments in databases is the use of combinatory logic for
> optimization).

No doubt you know a lot more about these things than I do. I was only
thinking of a system where the query is a first class Scheme object,
kinda like a curried function. When the query is passed to the db, it
is turned into SQL (or not, if one is using flat text ;-), so I don't
so where the optimisation problem comes in.

cya,
Noel
-- 
Noel Welsh
http://www.dai.ed.ac.uk/~noelw/   noelw@dai.ed.ac.uk