On 8 Jan 2001, at 14:27, Jason Wharton wrote:

To: <IBObjects@egroups.com>
From: "Jason Wharton" <jwharton@...>
Date sent: Mon, 8 Jan 2001 14:27:07 -0700
Send reply to: IBObjects@egroups.com
Subject: Re: [IBO] Interbase,Advantage,Paradox

> > > 1. If it's performance you are seeking, there is NO WAY you
> > > should be using TIBOTable for an executable process. Put this
> > > statement into a TIBOQuery...
> >
> > Would a TIB_DSQL component not perform better for bulk inserts since
> > it
> does
> > not have the extra baggage associated with the TIBOQuery component ?
>
> Yes, this is the best component to use for batch inserts.
>
> > > 3. Forced writes will slow things down (as observed) but if you
> > > have a fragile network environment or users who habitually
> > > terminate a database session by switching the computer off, it's
> > > worth the cost.
> >
> > Really ? I have client sites where the users habitually terminate a
> database
> > session by switching the computer off. I have been trying to break
> > them of this habit for years, but without success. I was under the
> > impression that IB would solve this problem due to it's C/S design.
> > What kind of problems can I expect when this happens ? I realize
> > that any pending transactions will not be committed, but please tell
> > me my database will still be intact
> ?
>
> You are safe with InterBase. The only reason you want forced writes on
> is if you SERVER is ever susceptible to a power failure or your OS
> install is in flaky condition.

This really becomes a moot point, if the SERVER is susceptable to
power failure, then stick a UPS on it, preferably one that can signal
the SERVER, that the feed has failed so it can do a proper shutdown.

If the OS is flakey, then the problem causing the flakeyness should
be properly investigated and fixed. It's amazing the number of
companies that with spend $10,000 to upgrade a server so that they
get decent performance with a work around, rather then spending $700
to properly fix the problem.

> A failed client will not adversely affect the server's data integrity,
> period. That's client server.
>

> > > As a general comment, it doesn't make sense to force InterBase to
> > > behave like a file-based database (which it's not) and then expect
> > > it to
> compare
> > > favourably with file-based databases, performance-wise. The kind
> > > of "benchmark" you are trying to do is rather silly, for example,
> > > because
> one
> > > would never be inserting 1000 records from a table interface. The
> Insert
> > > and Append methods are intended for one-by-one manual inserts.
> >
> > I agree that this is a silly test, but it is probably one of the
> > first
> tests
> > that every BDE to IB convert tries. The table interface gives the
> developer
> > the warm fuzzies they had with the BDE TTable component and is a
> > natural selection.
>
> Get over it!
>

Now now, be nice, we all know that benchmarks are always done to
confirm a decision already made. However it's usually because
someone is doing something bass-ackwards.

In this case, there is an acceptable performance level, if the IB
solution isn't meeting that performance level (2 sec per entry),
then what is holding it back, could be a network problem,
a server sizing problem, a server tuning problem, a client tuning
problem, an inefficient client, or any of the 1500 other potential
problems.

> > > A further comment is this. Client/Server databases aren't
> > > intended for desktop use. If speed is your only criterion then
> > > stay with the desktop database. The transaction model is meant to
> > > preserve data integrity in
> a
> > > multi-user environment. It would be surprising if there were no
> > > cost to that. If your single-user app is getting broken by user
> > > behavior under Paradox, it won't get better by switching to
> > > another database.
> >
> > I would imagine that the majority of people migrating from Paradox
> > to IB
> are
> > switching for the improved multi-user support, but still need to
> > support a single user environment. I have found that IB performs
> > quite well in a single user environment as long as the app and
> > database are designed to
> take
> > advantage of IB's strengths. Reads, inserts and updates all appear
> > to be much faster. Could you elaborate on where IB might be slower ?
> > This could
> be
> > very helpful to newcomers like myself.
>
> IB will be slower than paradox if you are not taking advantage of any
> of the additional features and capabilities that InterBase has. With
> hardware ever increasing I really don't think this is a significant
> performance gap. InterBase is so efficient that it can and will do a
> good job in a single user environment.
>

Not everyone has the latest hardware, I type this on a Circa 1995,
Pentium 90, with a massive 40MB of RAM, and an enormous 2GB HDD, the
server that almost eveything runs on around here, including IB is a
Circa 1992, 486DX50, with 16MB of RAM, and a 850MB hard drive, it
runs Redhat Linux 6.1, so it's pretty efficient. The biggest reason
for using something like IB in a single-user environment, is that it
offers the single computer enterprise, the ability to add additional
computers in the future without needing to re-write an application.
That is a decision that can save thousands of dollars later on.

Paul








Paul Schmidt,
Tricat Technologies
Email: paul@...
Website: www.tricattechnologies.com