Re: too many fields, too many cards?
Thanks to all on this thread. What would I do without you guys? Comments are all constructive and sensible. I think I might have even understood them all! The tentative plan, for my stacks, is not to fix them because they don't seem broke. Cheers, Tim On Nov 29, 2006, at 8:22 PM, Jim Ault wrote: On 11/29/06 5:48 PM, Timothy Miller [EMAIL PROTECTED] wrote: 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? As an ex-HCard programmer I can say you got the idea and I would stay just as you are. On advantage you have is the medical history is not changed or rewritten, so most of your modifications simply add to the data stored. --snip-- ___ 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
too many fields, too many cards?
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
Re: too many fields, too many cards?
On 30 Nov 2006, at 01:48, 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. 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? I think you've understood the suggestion perfectly. My own approach would be to store the data for each patient in an customPropertySet, which is really an array (each one named the same as the patient, maybe, and each key of which I'd name the same as the field you're currently using), so to populate a single card stack: on showPatient patientName put the customProperties[patientName] of me into tPatientArray repeat for each line K in the keys of tPatientArray put tPatientArray[K] into fld K end repeat end showPatient and to store, after making changes on storePatient patientName repeat for with n = 1 to the number of flds put fld n into patientArray[the short name of fld n] end repeat set the customProperties[patientName] of me to patientArray end storePatient Something like this, anyway. But if it's working well for you as it is, then? Best, Mark ___ 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
Re: too many fields, too many cards?
Mark Smith wrote: On 30 Nov 2006, at 01:48, 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. 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? I think you've understood the suggestion perfectly. My own approach would be to store the data for each patient in an customPropertySet But that would make searching across the patient base even harder, wouldn't it? He might end up having to ask about matchtext or something... -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.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
