>> 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?
> 
> 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.

Sorry about the confustion. I didn't mean text items, but I had to give it a
name. Maybe 'units' would have been better, because that doesn't mean
anything in transcript (as far as I know). I meaned if for those units lines
would be the right solution (which seems to be according to the good
responce several of you gave; thank you all), those 'fields' would be text
items. Otherwise it would have become a stack with cards and fields or a
database with records and fields.

> 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.
> 
> 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.

The users will not see the data as a whole, but the script presents the
units one by one, alters some data and changes that line of data.

Thanks for the help you all.

Terry


_______________________________________________
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Reply via email to