Database vs Cards
sarahr at genesearch.com.au
Sun Oct 13 18:33:01 CDT 2002
If all the cards have the same structure, you can group all the objects
and turn on the group's backgroundBehavior. This way all the objects
are created automatically on any new card. You can also put your
scripts in the group or it's objects, so that they really only exist in
The cards method is much the easiest to learn and implement but with
3000 cards, it may turn out too slow. The next best option is probably
to have a data storage section and a display section. Suppose you are
storing names & addresses. Instead of having one per card, you could
enter them, then amalgamate all the data fields into a single line
separated by tabs or some unusual character. When you need to display
that data again, get the line, set the item delimiter to whatever
character you chose and place each item in the appropriate field.
This method allows very fast searching using the filter command or
lineOffset. Also, if you build the application, the display stack can
be the mainStack (so not writable) but your data can be in a separate
subStack and able to be saved.
On Monday, October 14, 2002, at 08:56 am, Mike Doub wrote:
> I am planning the design of an address book like application. I have
> studying the Employee database tutorial and have noticed that the
> are duplicated on each card. I am planning to support about 3000
> That would seem to be pretty wasteful.
> Can anyone comment of their experience with lots of cards? I am
> with both memory and performance. I have no experience with using a
> databases so I was trying not to lean in that direction.
> use-revolution mailing list
> use-revolution at lists.runrev.com
More information about the use-livecode