From: BlueChip <cs_bluechip_at_webtribe.net>
Date: Fri, 22 Oct 2004 15:36:55 +0100

>BlueChip wrote:
> > Not a key for each SPECIFIC search, but a key for each TYPE of search.
> > That is, not "abba+1985", but "group+year".
>
>I'm not sure I understand how you mean. Please elaborate.
>
>--
>Björn

Using this example (group+year) ...the key/index file for this search would
contain N records, where N is the number of files/records/mp3's/id3's being
indexed. Each record would contain an Artist, a Year and a Record
Number. The Record Number is the 'offset' into the main database of the
full details, such as filename.

The index is then sorted by Artist+Year making a binary chop possible.

The other alternative is to store the index as a (modified) binary tree,
but this requires considerably more code to create and navigate the tree,
but does not need to be tidied quite so often

The system I am using is the former (sorted keys) based on my work on
mainframes some 15 years ago.

This information should be considered in the light of (iirc) Fred's* and my
previous posts on DBase/XBase record structures ...As Fred said, these
systems were designed for ancient CP/M machines which had far less storage
space and cpu power than we do - this fact should hopefully offer you the
security of mind that the idea is, at it's very least, a very workable
solution for this problem.

BC

*You know how I'm awful with misattributing ideas, so sorry if the name is
wrong

_______________________________________________
http://cool.haxx.se/mailman/listinfo/rockbox
Received on 2004-10-22