General approach question

[Richard Gaskin]

Mark Smith wrote:
> I have an app for keeping track of stock and futures trades. The data is 
> effectively a list of days, each day containing a list of open trades, 
> one per line, with the details as items in each line. Currently, I have  
> this data in an array, with the keys being the date of each day, and 
> each element containing that day's open trades. I store the array in a 
> custom property set. This all works perfectly well, so I'm not about to 
> change it, but I can't help feeling that this is not a particularly 
> 'natural' way to do it in Rev.

If it's Transcript and it works, IMO it's "natural". :)

Some things are more convenient when stored in fields on cards, but 
arrays and even simple tab-delimited lists have their own conveniences too.

Cards may seem more "natural" to someone coming from HyperCard because 
with HC you had no choice:  it had neither arrays nor custom properties 
to store them in, and the built-in sort command only worked on cards; 
you had to use an external for anything else.

One thing to remember with storing data in fields is the object 
overhead.  Every object has a certain amount of overhead associated with 
it.  It's usually just a few bytes, but it can add up with large numbers 
of fields and/or cards.

I had a similar decision to make recently for an app I'm working on.  As 
a test case I used a tab-delimited list of Congressional contact info -- 
8 fields, with each line under 1k.  As a text file it's 64k, but 
imported into a stack (8 bg fields per card, 530 cards) it's nearly 
double at 122k.

On such a small dataset the size difference was negligible, so I decided 
to do some stress testing:  I used ten copied of the source data, giving 
me 5300 records.  As cards the performance was quite acceptable, but 
saving was slow.

So I decided to see just how slow it would get and I ran a larger data 
set with 100 copies of my source file.  It would have been 53,000 cards, 
but I'll never know:  after several long minutes it still wasn't done so 
I aborted the import.  God only knows what might have happened if I had 
waited and then tried to save. :)

The inventor of the engine, Scott Raney, once recommended to me to use 
stacks with only about 5,000 cards, and if you need more you'll get 
better performance using a database like Valentina for storage and 
retrieval.

But Dr. Raney overlooked the beauty and simplicity of his own custom 
properties.  I've worked on projects with tens of thousands of custom 
properties with narry a blink.

For a small data set like yours you could go either way. But if you're 
enjoying the convenience of transfering an array to properties and back 
in just one line each, there's no need to fix what's working. :)

For some other thoughts on use stack file properties for storage see:
<http://lists.runrev.com/pipermail/use-revolution/2002-July/006149.html>

--
  Richard Gaskin
  Fourth World Media Corporation
  __________________________________________________
  Rev tools and more: http://www.fourthworld.com/rev