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]

database access - Re: Scheme is too complicated


> One interface I'm familiar with is the one which makes an underlying
> database file look like an associative array (aka hash table).  This
> would mean (make-hash-table) would take some extra args (such as file
> name) & the hash table access routines would be different depending on
> the type of hash table created (gdbm, berkeley db, ...).
> 
> Is there another interface for more sophisticated databases?

For ordered structures such as trees, a fundamental interface offers
``insert'', ``delete'', ``find'', ``next'' and ``previous''.
Mostly this is implemented with so called dynasets (which are
pretty much equivalent to iterators, often with support for filters).

Typical filters available on dynasets are variants of ``sort'' and
``search'' in one form or another.

Fancier relational things offer merging functions like
``and'', ``or'', various joins, renaming of fields, using formulae
as fields, etc. By this time you should probably be using SQL for most
everything since that would have to be the biggest standard for relational
databases. A quick look over an SQL text-book should be an example of
commonly offered functions.

As far as I know, SQL doesn't support hash tables because there is
no way to tell it that you don't care about the sort order for your
table. Does anyone know the deal with this?

I haven't done much work with object-oriented databases so they
probably need some other odds and ends.

My routines will also generate a list of keys between two values
so that you can work over a piece of the keyspace. This could
easily be handled by using an SQL query to generate a filtered dynaset
and then stepping through that dynaset but I can't be bothered trying
to parse SQL so I'm just building what I need.

	- Tel