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