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 _______________________________________________ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
