[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