Thanks,
Each record in the table has fields of information. And the foreign key is
basically a field in the table (i.e. part of the record's data). Since the
index is assigned internally (correct me if I am wrong), this is not part of
the data so I do not really have control over this. Hence I cannot search
a database base on their ID or Index. Therefore, probably the search will
have to be linear. Or sort out the database and have it use quick sort or
something.
Eric Sun
Developer - RAD systems
Q. Data Inc.
5/10/00 2:32 PM
-----Original Message-----
From: Peter Epstein [SMTP:[EMAIL PROTECTED]]
Sent: Wednesday, May 10, 2000 1:02 PM
To: Palm Developer Forum
Subject: Re: Question about database sizes
Eric Sun wrote:
>My question is, are these database sizes normal (i.e. are other
people
>programming with such large databases?). I ask this because I am
having
>some trouble with going through each record for the first 500
records and
>then taking the foreign key to match a record in the second
database. This
>is taking about 15-20 minutes to go through it all. Is it because
of the
>database sizes or because of my limited knowledge with database and
the
>searching capability that Palm comes with?
When you say "taking the foreign key", are you referring to a record
unique ID or record number (index) or something else? Finding a record given
its unique ID requires a linear scan. That means that the operation you're
describing is going to get very slow: O(n squared). If, on the other hand,
you used record numbers to get from one database to the other, then each
access is nearly constant time. Of course, if you reference records by their
index, you'll need to update the references whenever you insert a new
record, and that might be too slow, depending on the sort order of the
database and the frequency of insertions. You might want to use a cache
approach where each record in the first database refers to records in the
second database using both a unique ID _and_ a record number. You try the
record number first, and if it has the right unique ID, you're done. If not,
you find the record by unique ID and update the record number. Again, this
will only be efficient if insertions are rare. It isn't easy to come up with
a design that works well with lots of data. Hopefully some of these ideas
can help you come up with a more efficient design for your problem.
--
Peter Epstein
Palm Inc. Developer
--
For information on using the Palm Developer Forums, or to
unsubscribe, please see http://www.palmos.com/dev/tech/support/forums/
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
