31142 lines/cards/records

[Ken Norris (dialup)]

on 10/22/02 8:18 AM, Terry Vogelaar at terry at discovery.nl wrote:

> I have 31142 items to keep track of and I wonder what the best approach
> would be to store them. Each item should have an equal number of fields,
> just a few, with not much text data in each. I could make a comma delimited
> field with 31142 lines, a stack with 31142 cards or a database with 31142
> records. I need to sort them in several ways and I wonder what the fastest
> way is to store and access the data. Any suggestions? What are the benefits
> of each solution?
----------
Terry,

Your question is a little confusing. First you say you have 31142 items,
then you say each item should have an equal number of fields.

This implies you have several separate text "items" for each item.

Both _search criteria_ (what 'ways' will you want to sort on) and _content_
must be known before you can decide on preferences for setting up any
system.

1) If you don't need to categorize, a single field (scrolling I assume)
might be the fastest way to find and sort, but the mechanics of scrolling
through a field with that many lines will likely be painfully slow. Also,
will you be adding lines? If so, where? In other words, you may need to take
editing features into account.

2) If there is any chance you will want to add other data, you should
consider the stack of cards. You will have more space to work with, and all
the data is still searchable.

3) If you will want to categorize, you should consider a main stack with
substacks. This way you can set up a table of contents and/or index, and/or
several different search methods, and set it up to sort or edit each
substack separately, which, in this case, would be faster than searching and
sorting the whole list.

4) Develop a stack with a search-sort-edit engine that can modify results
and can, itself, be modified, as a front-end UI, to access external data
stacks or files. This way, you can bring in the data and sort, search,
and/or edit however you like without affecting the original data until you
save it back. This may be the slowest, but it allows for easy backup, more
security, and an ability to modify the operating stack features without
affecting the data.

HTH,
Ken N.