> In a debate on comp.databases.oracle.server
> I was engaged in a debate about IB/FB's
> MVCC model and various other issues about
> whether IB/FB was a "toy" db - exclusively
> Oracle people tend to be very snobbish about
> other RDBMS's to the point of downright
> ignorance, rudeness and stupidity.
>
> Anyway, as part of this debate, I wrote a
> post of analysis/opinion (my own) as to the
> reasons why IB/FB (well IB really, because
> it has more to do with the history than
> today's situation) doesn't have a bigger
> share of today's database market and wouldn't
> be seen as a major player.
>

Hi Paul,

I have read with interest all of the posts in this thread to date (I
haven't yet absorbed it all, that will take weeks). You do raise an
interesting point about market share. Personally, I find it hard to
compare figures because it is not apples and apples. There are a
number of factors IMO that explain the great variations between
reported deployments and job ads.

* Surveys may be asking the wrong question, making Firebird look more
popular than it is.
* Employers do not always want to list their exact DBMS. I know we
didn't when we last employed a developer. Perhaps they think Firebird
is too unknown, or that because it is easy for anyone to pick up, they
don't want to eliminate potential candidates.
* Surveys are usually pointed out, I don't think anyone would bother
doing it 100 times as was suggested, but perhaps more people feel
ablidged to say "yes I use it" than they would for say Oracle.
* A lot of surveys target the Delphi crowd, and there is a very well
established component option for DElphi.

But when it comes to comparing FB and Oracle, on one hand, you have a
DBMS with an expensive license that requires a DBA, on the other, you
have a DBMS that you can stick on a USB key if you want, and apart
from a once off check of about 10 settings, and a once a year backup
restore cycle, requires no DBA.

Our product is used at over 300 sites of 50 organisations. There is
not a dedicated DBA at any of the sites, nor is there a dedicated DBA
to manage the 50 databases. It uses an n-tier model to gather
information at each site and communicate with the server in real time.
We are investigating replacing the simple text files used for tier
level storage with embedded Firebird, and I have built some proof of
concept code. If this project gets the green light, then that will
immediately boost our "Firebird deployments" by a factor of 7 or 8.
While text files do the job adequately, there is something nice about
an ACID compliant data storage layer.

The point I am trying to make is that due to the simplicity of install
and low administration costs, and the fact that the slowest 10 year
old computer can run it, you would probably opt to use Firebird in
situations you would not even consider deploying oracle with.

So I guess you cant really consider an Oracle deployment the same as a
Firebird deployment. How can a small tier level database with three or
four tables with possibly 5MB of data and a 100GB database both be
called a deployment? Do not hear me say that Firebird can't handle
huge databases (certainly gbak would take forever), or Oracle can't be
used for small databases.

Technologically, Firebird arguably has a better implementation of MGA,
but it does not have all the features of the "big boys" yet. Firebird
2 goes some way towards addressing this, but we are still missing a
lot of the administration side of things (killing rogue queries,
setting timeouts).

Still, you would have to be pretty loopy to commit yourself to Oracle
better or worse. Just because you need the features of Oracle for some
project, doesn't mean all of those features will be required
in another project.

I believe Firebird has enough critical mass to continue growing. It
does not need 30% of the pie to be viable.

Adam