Stack file size

[xbury.cs at clearstream.com]

If I may, i will give you another opinion. I do use sql, filemaker, text 
files and
folders as well for database formats but there is one major advantage to 
cards...

The first one is that you can easily find and locate information. The 
second
is that editing is much easier. It's easy to sort and pretty fast access 
wise. Not
the fastest, i agree but for most purposes and in many cases, cards will 
be 
much more performant than most other formats - and in general, this covers
most storage formats...

Why not use a thousands cards? This is the same as putting a thousand 
records in a 
file or an sql table. Careful indexing will make access ultra-fast (faster 
than loading and
finding an offset in the list of data... 

Also at some point, spliting data from the cards to other stacks' cards 
makes sense
like you would separate tables in sql to improve performance.

Depends on the applications naturally. Static data as Signe Marie 
mentioned is 
one of those exceptions, and surely there's many more...

cheers
Xavier

On 26.05.2005 09:10:34 use-revolution-bounces wrote:
>Lars Brehmer skrev:
>> This is probably only of interest if you are a Rev user without much
>> coding expertise like myself and are working with stacks and
>> standalones that contain thousands of actual Rev cards, instead of
>> using a data base. >
>
>Hello Lars
>A suggestion from another language program developer: I would suggest 
that
>you get rid of the thousands of cards. When I started with HyperCard I 
used
>lots of cards. Now I just make one editing card for each model of
>exercise,then there is no need to have extra cards containing the data. 
All
>the relevant data is then put into a custom property either of the card
>itself or of the stack, or elsewhere. So no need for a database.
>
>Each time I need to change anything I go to the same editing card, 
fetches
>all the relevant data from the custom property and put them into the 
various
>fields, do my changes and put it back into the custom property.
>
>One simple example to make it clearer: For a gapfilling exercise you need
>only the card on which the student does the exercise + an editing card 
for
>the same exercise. Let's say you have 10 exercises with verbs. The 
relevant
>data may be like this:
>1. w3 r2 The boy fetches water.
>2. w2 r8 Mary wants to study English.
>etc.
>
>I usually put all the relevant data into the same phrase. The second word
>(w3) indicates the word to be filled in, the third word (r2) is a 
reference
>to a rule etc. In this way I use just one field on the editing card (for
>instance called "datafelt".
>
>On the exercise card the word no. 3 will be replaced with ... or --- or 
____
>or similar in the first phrase, word no. 2 in the second phrase. The same
>words are the key which the program matches with the student's answer.
>
>The set of sentences is then saved into a custom property:
>
>put "datafelt" into f
>put "gr" into kust -- for the grammar exercises
>put "Ver" after kust -- to indicate a verb exercise
>put "3a" after kust  -- to indicate which number and that there may be a 
3b,
>3c --as well
>set the kust of this cd to the htmlText of fld f
>
>Then each time you need to make changes, you go to the editing cd,fetch 
the
>data and put it into fld "kustfelt":
>
>ask "Which exercise?" with "grVer" --You have to add the number
>if it is empty or the result is "cancel" then exit mouseUp
>put it into kust
>set the htmlText of fld "kustfelt" to the kust of this cd
>
>htmlText is used in order to maintain the various diacritics across 
platforms.
>
>If you need further help, don't hesitate to mail me offlist.
>
>Signe Marie


-----------------------------------------
Visit us at http://www.clearstream.com
IMPORTANT MESSAGE    Internet communications are not secure and therefore
Clearstream International does not accept legal responsibility for the
contents of this message.    The information contained in this e-mail is
confidential and may be legally privileged. It is intended solely for the
addressee. If you are not the intended recipient, any disclosure, copying,
distribution or any action taken or omitted to be taken in reliance on it,
is prohibited and may be unlawful. Any views expressed in this e-mail are
those of the individual sender, except where the sender specifically states
them to be the views of Clearstream International or of any of its
affiliates or subsidiaries.    END OF DISCLAIMER