too many fields, too many cards?
ambassador at fourthworld.com
Wed Nov 29 22:28:27 EST 2006
Timothy Miller wrote:
> I guess you're suggesting the stack could read from a custom
> property or a text file to fill in the fields in just one card,
> based on a unique identifier for each patient. That's not too much
> different from a database inquiry, if I understand you. I guess I
> could search faster that way, in theory, but otherwise, I don't see
> the advantage.
There may not be; storing data on card can be pretty convenient.
As long as the number of records is unlikely to exceed 1000 and almost
certain to never exceed 5000, using cards can be okay.
With larger numbers of cards, the overhead of packing and unpacking the
card records shows its ugly hand, slowing performance down in many key
areas, most noticeably with saving, since Rev packs up and saves all
cards at once (as opposed to more corruption-prone systems which page
cards from disk and leave you no control over when things are saved --
everything in computing involves trade-offs <g>).
Using custom properties can be handy for larger numbers of records. My
favorite is simple tab-delimited lists, often stored in a custom
property so I can have any number of tables, and even non-tabular data,
convenient stored in one file.
Custom props and lists can be very efficient for data sets below 10,000
records, and reasonably acceptable up to about 50,000, sometimes more.
If you need closer to 100,000+ records, it's definitely database time.
Personally I avoid all database engines as much as I can unless I
absolutely have no choice in the matter. For some apps like iTunes I
suppose they have a place, but I tend to make very traditional
document-centered apps and such apps become difficult in a world where a
database vendor controls your application's file structure (not to
mention most of them requiring multiple files -- eew).
Fortunately, most of the document-centric apps I make are such that the
user will almost never need more than 10,000 records (that's an order of
magnitude more in some cases), so I can enjoy breezy data storage and
access using native Transcript, no fuss no muss.
Managing Editor, revJournal
Rev tips, tutorials and more: http://www.revJournal.com
More information about the Use-livecode