Database vs Cards

[Sarah]

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 
one place.

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.

Cheers,
Sarah


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 
> been
> studying the Employee database tutorial and have noticed that the 
> scripts
> are duplicated on each card.  I am planning to support about 3000 
> entries.
> That would seem to be pretty wasteful.
>
> Can anyone comment of their experience with lots of cards? I am 
> concerned
> with both memory and performance.  I have no experience with using a
> databases so I was trying not to lean in that direction.
>
> --Thanks
>    Mike
>
>
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/use-revolution
>