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