On Wed, Apr 13, 2005 at 12:19:23PM +0200, Bjorn Bringert wrote:
> Frederik Eaton wrote:
> >I'm thinking about implementing special indexing data structures over
> >SQL tables in databases that might not support those structures
> >natively, for instance an R-tree for multidimensional range queries (I
> >think mysql supports only up to dimension 2) or a simple balanced tree
> >for fast calculation of a running total of a given column. (data
> >structure links would be to primary key columns of tables)
>
> Thiat sounds like an interesting project.
I thought about it some more, I think doing it efficiently, minimizing
database communication round-trips as well as file IO, would require
using structures like B-Trees and storing large "blocks" of binary
data in columns and parsing these out on the client side. Not quite as
pretty but still possible.
> >I thought that haskelldb might be a good candidate for such an
> >implementation because of the ability to achieve modularity by
> >composing query functions, and also the potential to minimize context
> >switches by sending large chunks of SQL code to the server at once...
> >But presumably the datatypes would require atomicity in the form of
> >locking or transactions, which haskelldb would have to support, as
> >well as 'if' statements or 'if' functions for logic. An alternative
> >would be to write stored procedures directly in SQL. (can haskelldb
> >generate these?) A separate issue is enforcing type constraints, such
> >as saying that an 'id' value in a certain column can only be used to
> >look up elements of certain other columns, it seems like it could be a
> >capability of haskelldb, is it?
>
> HaskellDB already has support for transactions (with MySQL I think you
> need to set the table type correctly for this to work, see the MySQL
> manual) and if functions. There is no support for stored procedures,
> though it could be a nice project for someone to look at.
>
> For the id columns, do you mean that one couldn't get at the actual
> value, just use it to look up other values? Or what is the type
> contraint here?
I don't know. I guess you wouldn't *need* the actual value if it was
just for looking up rows in your database, although you might want it
if it's also an index to external entities. So even if it's just an
Int underneath, it could be wrapped in something semi-opaque when
you're manipulating it in HaskellDB to mark the "virtual type", and
this would not be an inconvenience. But I think you already understand
the purpose, there should be various ways of achieving it nicely it if
it's deemed useful. Maybe specifying virtual types as part of the
schema or something,
Frederik
|