General approach question
Richard Gaskin
ambassador at fourthworld.com
Thu Apr 21 19:38:12 EDT 2005
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
More information about the use-livecode
mailing list