>Um, as far as I know, this is a problem with ANY SQL-based DB (oracle et
>al).
There's abysmal and then there's merely appalling. :)
What surprised me is that a simple "select * from tablename" TQuery
performed so much better than an equivalent TTable, in Interbase. Can't
really compare this to other sql-based db's as they're not available to me.
Interbase is in a unique position in the market in that it's competing with
both the really big players (Oracle et al) and the small local players
(Paradox et al). To people debating whether to go with Oracle, for example,
or Interbase, then the issues of support, cost, and performance on huge
quantities of data are far more important than this discussion.
At the moment I'm among those at the other end of the market, those who have
gone with a local sql database, Paradox or whatever, for speed and price
reasons. Obviously if you're in that situation you're not going to want to
switch to a real client-server database, no matter how many extra benefits
you receive, if performance degrades by a factor of ten - and that's exactly
what I found, going to a local Interbase database (it would be unfair to
expect connection to an Interbase server on another machine to perform even
as well as that). And that's when accessing only thousands of records, not
millions. The good, and surprising, news is that performance when using
queries is just as good in Interbase if not better than local table
performance in (in this case) FoxPro. So the long term prognosis for
changing databases is positive.
All I'm saying is that if you have an application running against, for
example, FoxPro, which only ever performs acceptably when using TTables and
SetRange, so that the application will be coded appropriately, and you want
to change to a better database (suppose you'd just seen the article
http://community.borland.com/article/0,1410,21774,00.html :), it still won't
be worth it unless you can afford to take time to rewrite all your code.
Using queries or IBO, IBX, whatever. Your apples to apples comparison may
not be apples to apples, but for comparitive purposes it's nett speed that
matters.
Incidently, I've heard the argument that local performance with tables
_should_ be bad with Interbase compared to that with a local sql dialect
before. What it doesn't explain is why Interbase's performance with queries
is so good! If it's just a matter of locality and indirection, they should
both suffer to a similar degree. If Interbase ran half as fast using tables
as it does using queries, I'd just shrug and go "well, TTables are rubbish -
we knew that. At least we can use the old system until it gets rewritten".
But one tenth as fast?! Do other sql dialects suffer this bad? It should
be shouted from the rooftops...
Cheers,
Carl
-----Original Message-----
From: Nic Wise [mailto:[EMAIL PROTECTED]]
Sent: Thursday, 27 April 2000 11:49 AM
To: Multiple recipients of list delphi
Subject: RE: [DUG]: Interbase problem??
> There's another issue with Interbase that people considering a
> change should
> be aware of. Interbase's performance when using TTables through
> the BDE is
> absolutely abysmal.
Um, as far as I know, this is a problem with ANY SQL-based DB (oracle et
al). It comes from
doing
select * from table
then get all the records. Not good in a 5 million row table :)
where an ISAM db just reads records as needed.
Try and apples-to-apples comparison:
Paradox:
table.first
while not table.eof
inmemorylist.add(table1.currentRecord);
table.next;
IB:
select * from table
which ever way you look at it, getting a complete table down is ALWAYS going
to be somewhat quicker in an ISAM situation - you can seek directly to where
you want within the file. SQL has other advantages (joins, SP's, triggers,
RI, etc) that IASM/file-based just can't do well.
It also might depend where your cursors are - client side needs the data
local, server should use the server's internal cursor system, and should be
a LOT faster. You might also want to look at the BDE properties for the
connection - especially the MAXROWS and SQLQRYMODE parameters.
:)
N
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
