Re: EDS
On Fri, 10 Mar 2000, you wrote:
> A few more suggestions:
> A compression tool would be great - it could rearrange all the records so
> there are no free blocks and everything is contiguous. A sort of a defrag for a
> database. This would be ideal for when (if) you end up with a large collection of
> tiny blocks of free space that were partially filled by another item, but nothing
> else will be small enough.
> Any ideas why the delete takes so long? Twice as long as insert on my
> computer. Does it wipe over all the unused space?
I've been trying to decide whether to mention this or not. I don't want to
discourage progress with this new Euphoria database, but there are some
things that really should be considered:
I have been using Euphoria successfully with small databases containing
600-1000 customer records and 2000-3000 A/R transactions. Much more than that,
and the read/write times begin to get annoyingly long. Too long for automatic
updates after each change, which is the way I prefer to do things.
Rob's compact EDS file structure may improve read/write speeds somewhat; I
haven't been able to port any test data yet, so I don't know, but as it stands
this limits the use of Euphoria to only the smallest business apps.
Larger databases, the kind needed by all but my smallest client, need to track
anywhere from a couple thousand to 90,000 customers and their transactions per
month. Most clients also need multi-user capability. The "whole ball of wax"
method (load it all into memory, then write it all back) just won't work in
these situations.
I need the ability to lock individual records, make a change, and write the
change back to disk (quickly) before unlocking the record for someone else to
use. I see no way this can be done without some kind of fixed size record. Too
bad, because otherwise, Euphoria would be the language of choice. It does
everything else quite nicely, and lets me develop apps quickly (always an
important consideration).
Regards,
Irv
|
Not Categorized, Please Help
|
|
