Db tables (was okKeypress)
George wrote:
>
> OK, that's a lot more than I probably needed to know..I certainly got the
> wrong idea in my head somehow...So we shoudn't have to worry about
changing
> tables or DB's...
>
George:
A quick test with a database of 52041 records shows a time to open the
database and
select the table containing those records to be 0.22 seconds. Changing to
another table,
and subsequently re-opening the first table takes consistently 0.11 seconds.
This seems fast enough. Writing your own indexing scheme is a bit of a
bother, but hey,
we used to have to do that all the time. Store the indexes as additional
tables in the database.
No need to have extra files scattered around.
Don't forget that you can store any amount of data in a record.
Suppose the product file above contains products made by 100 different
manufacturers.
Your Mfg_Index table would contain 100 records, keyed by manufacturer id,
and each record would contain a sequence of one or more product id numbers.
e.g:
key ACE, data {203453,104305,439322,493953,493955...........}
key BART, data {040323}
This makes selecting products by manufacturer a matter of one read from the
Mfg_Index table, and then a loop thru the list of product id's retrieved,
accessing
your product table once for each key on the list. One table change for each
index
consulted, plus one to return to the main table, and no extraneous reads
whatsoever,
just one for each product appearing on the retrieved list.
You can see that it would be no great problem to retrieve several indexes,
and then
combine and/or sort them before extracting the data.
Regards,
Irv
|
Not Categorized, Please Help
|
|
