[Haskell-cafe] relational data representation in memory using haskell?

Dan Weston westondan at imageworks.com
Wed May 21 21:07:15 EDT 2008

Consider SQLite [1], which is "a software library that implements a 
self-contained, serverless, zero-configuration, transactional SQL 
database engine."

It is embeddable, can reside completely in memory (including the data), 
and can be saved and restored to disk when needed. It neatly fills the 
niche between maps and a client/server database model.

It has a C API which you can wrap as needed with the FFI, and you 
wouldn't need more than a dozen or so functions to start with (it 
understands SQL too).

[1] http://www.sqlite.org/

Marc Weber wrote:
> On Wed, May 21, 2008 at 05:05:21PM -0700, Jeremy Shaw wrote:
>> At Thu, 22 May 2008 01:04:24 +0200,
>> Marc Weber wrote:
>>> Some way representing relational data which is typically stored in
>>> databases such as Postgresql..
>>> Rewriting something like Postgresql in haskell would take ages..
>>> So I'd be satisfied with having in memory representation only (this
>>> would fit the HAppS state system very well .. :)
>> Are you familiar with the HAppS IxSet library? 
> Yes - not with all that sybwith-class stuff though.
> There are some issues:
> its dynamic : doesn't this waste some CPU cycles?
> no multi indexes..
> maybe some space leaks because the data type containing the Maps is
> build after each filter maybe leaving unevaluating chunks - Saizan has
> told me about it on HAppS.. And you can't extend it to the degree I'd
> like to (eg throw a query at it and let the system figure out which
> indexes to use)
> And last but not least: It does'nt support relations at all yet.
> So all the effort adding / checking foreign keys etc has to be done
> anyway.
> Thanks Marc
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

More information about the Haskell-Cafe mailing list