Subject Re: [ib-support] MySQL vs Firebird - the slow decay
Author Ann W. Harrison
At 05:45 AM 9/24/2002 +0000, Andrew wrote:

>MySQL just got authentic transaction support.

Look at InnoDB closely and you'll find a lot of stuff that
Firebird does better. This quote alone should suggest where
the problems are:

"The physical size of an undo log record in the
rollback segment is typically smaller than the
corresponding inserted or updated row. You can
use this information to calculate the space need
for your rollback segment."

Calculate the space for the rollback segment? Or this...

"Every InnoDB table has a special index called the
clustered index where the data of the rows is stored.
The records in non-clustered indexes (we also call
them secondary indexes), in InnoDB contain the primary
key value for the row. InnoDB uses this primary key value
to search for the row from the clustered index. Note that
if the primary key is long, the secondary indexes will
use more space."

Data in the index? My, how purely 1965.

>God forbid they get before/after triggers.

Or, say, subqueries...

>1. Firebird lacks developers and consequently is progressing very
>slowly. Why the lack of developers? Is there even a need for faster

That's right. On the other hand, every line of code in MySQL
is written by an employee of MySQL. They can afford to pay
developers for two reasons: first, they've got a substantial
amount of investment. Second, they use the GNU license for
open source projects, but charge normal licensing fees for
commercial projects.

>2. Firebird no longer has a lot of the unique features that once
>distinguished it from the pack (e.g. multi-generational). Why is a
>Firebird feature better than the same feature implemented on another
>DB platform?

It's not, but we've still got some things that are better - our
index retrieval algorithms are very good, we handle inserts very
fast and our system management costs are tiny.

>3. Firebird does not have the profile ('buzz', 'hype', whatever) that
>it needs to become a widely used (i.e. widely known) RDBMS. Is there
>a need for a higher profile? What would result from a higher profile?

More users, more buzz, more awareness, more users ... Without
budget or charismatic leadership, this is tough. Making it tougher
still, I think that one of the beauties of open source development
is the ability to share ideas with other database developers, so
I'm giving away all our secrets.


We have answers.