On Wed, 20 Aug 2003 08:43:42 -0700, "Jeff Ishaq" <[EMAIL PROTECTED]> wrote:
>I am curious about your implementation. If a record in DB1 >refers to a record in DB2, what constitutes your primary key in this >relationship? In other words, if not the Unique ID, what do you store >as the 'index' of the referred-to record in DB1? Well... indeed there's a requirement that the records in DB2 have to be sorted by a unique key. That might not always be true, for instance, if you are storing patients sorted by their names, then you can't do a binary sort to find a patient (the name might not be unique, so you need something like a patient number, and you don't know what order they will be in). In that case the method I described wouldn't work. But suppose DB2 contains test results; each test result is assigned a date and a number in the day: the test records are sorted by date and day number. So database DB2 looks like: date day number test data 01/01/2003 1 data.... 01/01/2003 2 data.... 02/01/2003 1 data.... 02/01/2003 2 data.... If you need to sort on another key, then in DB1 each record contains the sort key, date and day number. The date and day number allow you to call DmFindSortPosition and find your test result in DB2. In the case I first mentioned, where the binary search doesn't work, then I guess I would have to use your method; I'm a little bit worried about two things though: 1) performance on a big database :we routinely have databases with something like 10000 records. When I have some time (which should be pretty soon, maybe in 2015) I'll try to benchmark that. 2) I don't trust that "unique" id ; there have been discussions in the past here and the conclusion seemed to be that it's unique most of the time, and that there's very little chance that it might be duplicated, the probability is low, blah blah blah, and that disturbs me because I am an obsessional paranoid who should seek professional help (but right now I'm busy writing software)..... I don't remember exactly, but the issue was not only wrapping but it had to do with seeds and synchronization and stuff like that. You can search for it on this forum though. Thus my feeling right now is that I would do everything I can to continue using the binary search method, even if it means reorganizing the data. For example, patients could be sorted not by name but by a patient number. There could be an index database on the side where the patients would be sorted by name. Then, the patient number would allow you to find the patient record by doing a binary search on the patient number. This would allow me to have other index databases to sort on other info. I might change my mind after benchmarking though.... What's that OS6 database stuff you keep mentioning? I read things on OS6 but saw nothing about that... Got a link? Olivier Lancelot -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
