Re: Comparing databases

On Saturday 22 November 2003 12:17, Paul Ganainm wrote:
> xzilla(at)users(dot)sourceforge(dot)net says...
>
>
> Hi all,
>
>
> I am very familiar with Interbase and Firebird. I have recently started
> looking at PostgreSQL, and I am currently reading extensively about it.
> I don't wish to start a flame war or anything, but some of the claims in
> this post are just downright wrong - it's a bit like PostgreSQLers
> giving out about M$ or Oracle or <insert vendor of choice> making false
> claims about Open Source software.
>
> Interbase/Firebird is probably (at least as far as I can see) the
> closest to PostgreSQL in terms of other available databases, and while I
> have no objection whatsoever to anybody pointing out the benefits of
> PostgreSQL, I really feel that it shouldn't be done by telling
> mistruths.
>
Wow, I think your response here is even more unfair than my initial post. Let
me quote my original email:

"I also can't speak to the accuracy of my listing of the other databases, if
you have recent experience with them please add or subtract as you see fit."

I said that precisely because I had a good feeling that my knowledge of some
of these database is limited, and I was hoping to garner the most accurate
information possible.

> > PostgreSQL 7.4 Pros:
> > -- Extensible Architecture: create your own types, aggregates,
> > functions, operators, libraries.
> >
> > 73-> now allows ploymorphic functions
> >
> > vs-> oracle, db2, m$, mysql, firebird
>
> Firebird offers functions and libraries and the ability to create your
> own types.
>

I also think you misunderstood exactly what I am presenting in this breakdown.
My listing of databases is not a listing of deficiencies in the other
databases. Again, I'll quote the original email

"... followed by short list of database that the particular pro stacks
up against."

AFAIK, and I could certainly be wrong, the level of support in postgresql for
custom operators, types, aggregates, libraries, and functions is superior to
any of the databases listed here.

A good example is our function language support. While most of the databases
above support some type of procedural language, do any of them support more
than 10 different types of procedural languages? Or do they have an
extensible enough codebase that can allow people to create their own
languages, like Joe Conway recently did with plR, or the folks at Command
Prompt have been doing with plPHP? (Of course this assumes you even have
access to the source code in the first place!)

That is what I mean by "stacks up against", when comparing databases, this
would be a feature worth highlighting from a <postgresql advocates> position.

BTW - Was just reading that M$ plans to support the CRE in Longhorn by 2005,
which will give developers the ability to write stored procedures in many
different languages.

> > -- 100% Open Source Community Controlled: contributions are not
> > controlled by any single company, so your suggestions and patches are as
> > good as anyone's.
> >
> > 73-> two additional companies now sponsoring core members
> >
> > vs-> oracle, db2, m$, mysql, firebird
>
> Firebird is fully Open Source. No flame wars about the particular
> licence please. MySQL is also Open Source - you may not like the fact
> that you have to pay for it if you use it in commercial apps, but it is
> Open Source.
>

I seem to recall reading that most of the firebird core developers all work
for the same commercial company, perhaps that is not true?

In any case, it certainly holds up with mysql, as Josh addressed in his
response. One thing he didn't mention, which I still think is true, is that
in order to have a patch accepted into mysql, you have to turn copyright over
to them for inclusion in their proprietary products.

> > -- Many support options: you have a choice of numerous support vendors
> > rather than being confined to one company.
> >
> > 73-> n/a
> >
> > vs-> oracle, db2, m$, mysql, firebird
>
> There are a few (perhaps not as many as several) vendors who support
> Firebird.

Right, but with PostgreSQL, you have 4 of the 5 core members all employed by
different support companies, and there are several other high caliber
companies to choose from on top of that contribute code back into the
project. Again, I just think that PostgreSQL's position in this department
is favorable compared to the other databases listed.

(BTW - the 5th member is employed by yet a 5th company, but not a PostgreSQL
support company)

>
> > -- BSD-licensed: may be used for commercial applications without fees.
> >
> > 73-> n/a
> >
> > vs-> oracle, db2, m$, mysql, firebird
>
> Oh dear - you most certainly *_can_* use Firebird for free in commerical
> apps.

Hmm.. I should have put the qualifier "closed-source" commercial applications,
since you can also use mysql with commercial applications as long as your
willing to gpl them. Does this still apply to firebird? My understanding is
that their license is sort of MPL-ish...

>
> > -- Multi-Version Concurrency Control (MVCC) ensures transaction
> > integrity, better scalability
> > 73-> n/a
> > vs-> m$, mysql
>
> It's a bit unfair to point at M$ here - locking and versioning each have
> their pros and cons.

i think Josh responded to this one already.

>
> > -- Database Programming: Support for functions and procedures in 11 or
> > more programming languages. Support for triggers, constraints, and
> > Rules-based query rewriting.
> > 73-> new pl lang (plr)
> > vs-> db2, m$, mysql, firebird
>
> In Firebird IIRC, you can write dll's or so's in any language you like,
> and use these as user defined functions.
>

Hmm... I'd guess there is something similar for folks running firebird on
*nix? Actually I'd guess that all of these database have *some way* of doing
this, but again, I don't think its as easy or as extensible as postgresql.

> > -- Responsive Community: Mailing lists offer peer-to-peer assistance
> > from major PostgreSQL contributors and advanced DBAs, often described as
> > "better than commercial support."
> > 73-> n/a
> > vs-> oracle, db2, firebird
>
> Here I really *_really_* have to object. The Firebird community has an
> excellent Community spirit, where those who contribute to the engine
> also help out end users.

OK, fair enough, but I don't see much permeation of firebird outside of the
firebird community. To be fair, postgresql is just starting to get to this
point, where you'll see support for postgresql in a wide range of software.
Heres an example, if I want to write php applications against firebird, who
do I do it? I just took a swing through the php function list and I don't
see anything that jumps out to me as firebird support. (fbsql turns out to be
frontbase support) I looked at the dbx module, which proclaims to support
frontbase, m$, mysql, odbc, postgresql, sybase, oracle, and sqlite. Where is
firebird?

Still, you might be right that firebird shouldn't be included above. I don't
think I have heard of anyone who left firebird because of the support level
from the community.

>
> > -- Durability: The PostgreSQL project is 16 years old, with years more
> > experience than most comparable databases, commercial or OSS. PostgreSQL
> > has already survived the death of several supporting companies and will
> > be around for a long time to come.
> > 73-> n/a
> > vs-> mysql, firebird
>
> Again, this is misleading to say the least. Firebird is a fork of
> Borland's Interbase, which dates from 1981, so Firebird already has the
> keys to the house (21) whereas PostgreSQL has yet to have its first
> legal drink (18).
>

Well, if you really want to pull out pedigrees, PostgreSQL is a direct
descendant of Ingres, which IIRC came about in 1977, which would make us 26.
But seriously, I think the point of the above is that our community has been
around for a long time and is well established. Firebird has only been on
it's own for a little more than 3 years and I think the biggest hurdle it has
had to overcome is the whole mozilla browser naming problem (which I think
the db folks were right in btw). Certainly the case can be made with any
open source software that it can truly never die, but if IBPhoenix were to go
under, how much of an effect would that have on the firebird community? At
this point I feel pretty confident that if any of our primary support
companies were to pull out, this community would just keep on moving.

So thats the long of it from our side, please feel welcome to educate us more
on firebird if you want. Should anyone decide to make a more permanent
document out of all of this I'd like for them to have accurate information.
For that matter, please also feel free to post things that you feel firebird
has an advantage on over postgresql, part of advocacy is being able to
address our weak points as well.

Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL