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
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Reply via email to