1. Future of EDS -- btree?
Regarding this database talk, has anyone attempted to write a btree
database implementation in pure Euphoria? One thing that prevents use
of EDS for really big databases (even if simple in structure -- one
giant table, for instance) is that it doesn't scale well after a point
(especially when adding new records, plus all of the keys are kept in
memory, which can be a problem if there are a gazillion of them). A
btree structure would potentially remain fairly speedy with millions of
records (the whole point of btree is too remain fast by minimizing disk
access), and it is not terribly difficult to implement (I've played
around with an in-memory version just to get an idea of how to code it
in Euphoria, but I never got around to making a disk-based version). Am
I mistaken?
2. Re: Future of EDS -- btree?
I have personally not attempted a database implementation in Euphoria,
but I have in some other languages, and have for the most part failed.
Creating a new database system is not an easy thing to do, of course.
I think all the major pieces are present, though. The most important
thing, as far as I know, is to be able to have access to pretty low
level byte based reading and writing functions for files without much or
any overhead. I'm not sure how fast Euphoria's functions for this are,
but I imagine they are simply wrappers around the C calls, and so
therefore quite fast?
~ Isaac
Andy Serpa wrote:
>
>
>Regarding this database talk, has anyone attempted to write a btree
>database implementation in pure Euphoria? One thing that prevents use
>of EDS for really big databases (even if simple in structure -- one
>giant table, for instance) is that it doesn't scale well after a point
>(especially when adding new records, plus all of the keys are kept in
>memory, which can be a problem if there are a gazillion of them). A
>btree structure would potentially remain fairly speedy with millions of
>records (the whole point of btree is too remain fast by minimizing disk
>access), and it is not terribly difficult to implement (I've played
>around with an in-memory version just to get an idea of how to code it
>in Euphoria, but I never got around to making a disk-based version). Am
>I mistaken?
>
>
>
>TOPICA - Start your own email discussion group. FREE!
>
>
3. Re: Future of EDS -- btree?
On 23 Jan 2004, at 2:04, Andy Serpa wrote:
>
>
> Regarding this database talk, has anyone attempted to write a btree
> database implementation in pure Euphoria? One thing that prevents use
> of EDS for really big databases (even if simple in structure -- one
> giant table, for instance) is that it doesn't scale well after a point
> (especially when adding new records, plus all of the keys are kept in
> memory, which can be a problem if there are a gazillion of them). A
> btree structure would potentially remain fairly speedy with millions of
> records (the whole point of btree is too remain fast by minimizing disk
> access), and it is not terribly difficult to implement (I've played
> around with an in-memory version just to get an idea of how to code it
> in Euphoria, but I never got around to making a disk-based version). Am
> I mistaken?
Jiri and others have written "associated lists" that do that, in various ways.
Bach has "hash tables".
Kat
