Re: Haskell as a relational database language

[S. Alexander Jacobson]

I built a codebase w/ Derive (or whatever is is called now) that takes a
haskell data types and generates haskell functions 
1. create tables to store the data types
2. take instances of the data type and output corresponding SQL insert
        statments
3. generates summaries of these tables based on using special purpose
sumarization types in the datastrucure 
(for a data warehousing application)

It would definitely be nicer if we could avoid the intermediate step of
going through a relational database...
How usable is the functionality you are describing?

-Alex-


On Tue, 15 Dec 1998, Torsten Grust wrote:

> Hi,
> 
> On December 15 (01:45 +0000), Michael Hobbs wrote with possible deletions:
>  | Tom Pledger wrote:
>  | > In the last 12 months or so, all the database-related messages in this
>  | > list have involved interfacing to SQL engines.  By contrast, how about
>  | > using Haskell as a non-SQL relational database language?
>  | 
>  | I've always thought that a functional language such as Haskell would
>  | provide a very good framework for using relational algebra in order to
>  | combine and extract data. (In contrast to using something like a
>  | Structured Query Language.) I dabbled with this a bit, but didn't get
>  | very far before I lost interest. :)
> 
> You might be interested in our work on mapping SQL (resp. OMDG's OQL)
> to the monad comprehension calculus and, subsequently, a combinator
> representation that is finally cheaply deforested to obtain a---how
> the database folks call them---streaming program from an algebraic
> query.  The streaming paradigm of query evaluation and the notion of
> tree-less functional programs are remarkably close, IMHO.
> 
> A broad range of heuristic query optimization approaches turn out to
> be simple rewriting steps in the monad comprehension calculus.  That's
> esp. true for queries involving aggregates, grouping, and
> quantification (but for the vanilla select-from-where query as well),
> ie. for a class of queries which isn't mapped easily (if at all) to a
> "classical" relational algebra.
> 
> If anyone is interested, details on all stages of the query
> compilation and optimization process in such a purely functional
> framework are described in a range of articles that can be found
> hanging off my homepage.
> 
> I also recommend to have a look at Leonidas Fegaras' (Univ of Texas,
> Arlington) excellent work in this area (http://lambda.uta.edu/).
>               
>   
> Best wishes,
>      --Torsten
> 
> 
> P.S. The connection between the database and FPL communities is
>      quite tight, IMHO.  It always has been (the functional data model
>      [Shipman et al.] dates back to the 70's), and it is today:  Kluwer
>      publishes a Special Issue of its JIIS on the ``Functional
>      Approach to Intelligent Information Systems'' early next year.
> 
> -- 
>   | Torsten Grust                              [EMAIL PROTECTED] | 
>   |                                   http://www.fmi.uni-konstanz.de/~grust/ |
>   | Database Research Group, University of Konstanz (Lake Constance/Germany) |
>  
> 

___________________________________________________________________
S. Alexander Jacobson                   i2x Media  
1-212-697-0184 voice                    1-212-697-1427 fax