This is the mail archive of the guile@cygnus.com mailing list for the guile project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
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"