too many fields, too many cards?

Timothy Miller gandalf at doctorTimothyMiller.com
Wed Nov 29 20:48:15 EST 2006


A long time ago, I complained to bugzilla that the native RR search  
stack is way too slow. Personally, I've found ways to work around  
that. I still think it's an unnecessary embarrassment for RR, that  
wouldn't be very hard to fix. But, that's not why I called.

Someone made this comment about my complaint. I don't doubt the  
constructive spirit of the comment, but I have a few questions about it.

The comment, in part:

>>
>> Then again, one should not store data in fields on 100s of cards.  
>> Instead, store
>> your data in a custom property or a text file. Although the search  
>> stack could
>> be greatly improved by making it much simpler, the problem is  
>> mainly caused by
>> the approach chosen by the programmer.
>>

My reply, in part:

I have a stack called "Patient information". The purpose is obvious.  
For each patient, there are dozens of items I need to keep track of  
-- more than 100, really. Name, address, various phones, diagnosis,  
referring MD, referring MD's ID number, patient's ID number, group  
number, account number, employer, etc. That's only a representative  
sample. I do a lot of complex chores with this stack, so there are at  
least fifty bg buttons, too. At any given time, I have records on  
maybe 500 patients.

The stack works fine in every respect, except the RR "search" stack  
is way too slow. I've written several of my own specialized "search"  
scripts for this stack and others. They meet my needs and are plenty  
fast. I avoid the native "Search" stack.

A field for each item and a card for each patient is the only way I  
know how to do what I need to do.

I guess the alternative is to use a database, with SQL inquiries.  
That would be faster, once I made the conversion, but this stack  
started as HyperCard and has grown and evolved over many years. I  
can't afford to spend the time to re-write it from scratch, and learn  
how to use a database and SQL along the way. It would take a hundred  
hours, or more.

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.


My question:

Have I understood the general idea here? Am I overlooking anything  
fundamental? Is it reasonable to leave well enough alone, as long as  
I can find stuff in stacks this large, when I need to?

Thanks in advance,


Tim



More information about the Use-livecode mailing list