> One particular database vendor comes to mind
Oracle perchance....?:)
Graham
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Eugene
Chin
Sent: 10 May 2000 19:52
To: Palm Developer Forum
Subject: Re: Question about database sizes
Eric,
If budget permits, consider using a commercial database product that
has indexing implemented for you. This way you can have all the
foreign keys you want, and referential integrity will be taken care
for you. One particular database vendor comes to mind :)
"Eric Sun" <[EMAIL PROTECTED]> wrote in message
news:11110@palm-dev-forum...
>
> 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/
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
