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
_______________________________________________
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
