I was actually surprised to see (recently read the info on MySQL) that it
does not offer trggers, stored procedures or transactions... not sure
exactly how their "atomic" view of update methodolgy compares with or
handles an expected transaction regime (if that's what you were expecting to
get from MySQL) but they say their system, even though lacking in
transaction logic still avoids db corruption.. also goes on to say how easy
it is to correct corruptions with several tools aiding you in this
endeavour...
Bottom line... caching is an entire science in itself and I have trusted in
IB for many years now that there implementation is very good and compares
well with other DBs. It's often enough for me to see result sets returned in
milliseconds from very large databases, and if I hit the same request over
and over, while watching the CPU, there is very little impact. In fact, if
you've ever checked the CPU use of the ibserver process, on a large database
with 20-30 people connected all day every day.. well I'm always staggered at
how little CPU time the process uses over any time period.
my 2 cents
Alan
-----Original Message-----
From: Helen Borrie [mailto:helebor@...]
Sent: Saturday, 24 August 2002 13:20
To: ib-support@yahoogroups.com
Subject: Re: [ib-support] Data Caching by IB


At 10:18 AM 24-08-02 +0800, you wrote:

>I think Jack was referring to resultset caching,
>a feature present in the newer MySQL.
>Read somewhere about db benchmarks
>where MySQL performance "rivalled" Oracle simply
>because of this feature...
>
>Regards
>Kenneth

InterBase does and always did cache resultsets. Pieces of resultsets get
returned to the client in packets, the number of which is determined by
the
client request. But the resultsets don't outlive the transaction in which
they are generated and they are not available to other transactions. It
wouldn't make sense, would it?

Comparing MySQL and Oracle on this kind of test is "apples vs
oranges". Oracle, like InterBase, is a client/server system, designed to
provide concurrent a real-time views of the database state that are
particular to each user transaction. Freezing the database state in a
cache and dishing that up to other transactions is totally contradictory
to
a consistent view.

If you don't care about a real-time view, implement a re-usable cache. If
you do, don't even go there.

heLen


Yahoo! Groups Sponsor
ADVERTISEMENT



To unsubscribe from this group, send an email to:
ib-support-unsubscribe@egroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.



[Non-text portions of this message have been removed]