too many fields, too many cards?

[Richard Gaskin]

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.

--
  Richard Gaskin
  Managing Editor, revJournal
  _______________________________________________________
  Rev tips, tutorials and more: http://www.revJournal.com