>1. Does INDEX$ use the application memory to set up it's pointers?

You need to check how much memory is in your app when you setup an INDEX$
and I think the overhead is 12 bytes per index array for pointers.

>
>2. If so, then what is the advantage over a conventional array? (other than
>the insert & delete used with INDEX$)

You can resize it without losing any data. That's fairly important. Plus
you can dump the whole array to disk and read it back in but writing the
array as a block of memory. This makes disk access very fast.

>3. How are most databases implemented?

Indexed, keyed, and hashed.

>4. Should I just leave the database on the disk and search/modify through the
>file without loading the entire file into an array? (really slow)

This would depend on the size of the database you plan on ending up with.
If its one that will go on forever, you need disk access to the records and
it will be disk based from day one. In memory you'll have the index that
points to the records on disk.

If its one of those that "may" grow but not out of sight, you might be able
to use INDEX$ and load it all into memory. When memory runs short, you
simply tell the user to increase the memory size allocation.

In either case, record access is about the same speed. So displaying
information is the "easy" part. The two hard parts are "editing records"
and "deleting records" and "sorting". Ah make that 3.

This comes back to the "type" of records you want to store. If they are
"fixed" lengths, you're on the easy road. If they are variable, you got
major housekeeping work to be done. With a fix record size, you simply
replace a "deleted" record with a good "record" and mark it as used in your
index in memory. Easy.

With variable length records, you have way more work to do. When the user
modifies a record and it no longer fits into the originals "slot" so to to
speak, you add the "edited" record onto the end, then you mark the original
record as being "purgeable". At sometime your database run, you do a
"compact Database" and regain the space you lost by moving up the records
to fill the empty space. THEN you need to reindex the whole file so that
you know where the records actually are.

Writing database's is cause for major headaches. I usually sit down for a
few days and plan mine out on paper long before I even code the things. I
once wrote what I though was the perfect database. It used variable length
records and seemed to work like a dream. After using it for a couple of
months I noticed it was having problems. After searching for the cause I
missed the fact that although the database could have millions of entries,
my index table that linked me to the records was limited to 32,000 of them.
Sigh. Index tables need to be just as large as the database is going to get.

And by the way, once you get to a certain point, you feel like you might
just as well have used 4D and make it into a miniruntime. It would have
been easier.

Mel Patrick                               /'\   /'\
mailto:mel@...               (/\ \-/ /\)
                                            )6 6(
StitchBunny & PESkey Home :               >{= Y =}<
http://www.intergate.bc.ca/business/mel    /'-^-'\
------------------------------------------(_)---(_)---------