Re: db interface (was Re: Scheme is too complicated)

["Peter C. Norton" <spacey@inch.com>]

On Sun, Nov 01, 1998 at 06:41:44PM +0100, Sascha Ziemann wrote:
> Craig Brozefsky wrote:
> 
> > - More concise syntax for generating SQL than a series of string
> >   manipulations.
> 
> When you forget a required keyword, you will get the same error like
> that from a broken SQL query. Where is the difference?

That's far from the most common problem w/ sql.  The biggest problems come
in trying to figure out what SQL means by a given query.  If Craig and I
are thinking along the same lins, By using a library of queries you avoid
some of the biggest hassles of sql.  You also create a place where SQL
information is available for browsing.  
 
> > - Keywords make it easier to trigger various options in sql, and to
> >   setup your query. You don't have to deal with SQLs syntax like makin
> >   sure you don't put a comma after the last value in a list, etc...
> 
> Do you expect someone knowing about inner joins without knowing SQL?

I don't.  I do think its very useful to have something that can generate a
syntaticly correct inner join for a given database for you.  This is even
more helpful to beginners then to experts, but anything that helps you
avoid mistakes, and abstract from the particular database is good.
 
> > - Unified syntax for generating most SQL, would be independent of the
> >   backends incompatabilities.  So like in postgresql, I think the
> >   outer-join syntax is different than some other DBs.
> 
> If so, someone should fix that bug in Postgres.

It's not a bug in postgres.  If you read the literature you'll find the
sybase, oracle, MS sql server, I guess postgresql, and other databases
each have different syntax for outer joins.  At least the postgresql team
may listen to you. Try beating M$ into submission. 
 
> > - let's us do nice things like the example I previously gave with
> >   find-if and remove-if.
> 
> You can do nice things only when you do them in Guile. The normal
> database situation is, that the database and Guile do not run on the
> same system. 

I'm missing something here.  Every modern database is networked.  So it
seems you can do nice things from any workstation/server that can connect
to a database.  Which is the point. 

> Furthermore SQL is the only standardized way to access a
> database. If you don't want to kill you local network, you have to do as
> much as possible in SQL. This leeds to the situation, that you can use
> Guiles cleverness only for the query results. So even if you write a
> wrapper in Guile, which produces SQL, you will not be able to do more
> than SQL lets you doing.

I don't see this as an obstacle.  Guile can provide enhancements to typing
queries by hand.  Query builders and database middleware are both thriving
software niches.  I see no reason to not to engage in that niche with a
guile which is after all a library to make programming tasks easier. 
 
> >   (select       :fields '(field-list)
> >                 :from '(table-list)
> >                 :join-type 'inner
> >                 :qualifier (= fieldname value))
> 
> Why do you think that a query becomes easier when you throw away the
> grammatical structure of normal SQL queries?

For myself: because any time I start writing a database application, I
start doing this anyway.  It makes my work faster and easier to abstract
common queries into functions that take arguments that are consistant.  I
see others doing the same thing.  

-- 
Peter C. Norton                      Time comes into it. / Say it.  Say it.
spacey@pobox.com                   | The Universe is made of stories,  
http://spacey.dyn.ml.org           | not of atoms. 
                                   |
                                     Muriel Rukeyser "The Speed of Darknesss"