http://www.osnews.com/story/12081/Preview_of_the_Firebird_Conference_2005 Exploring the Future of Computing en-us Copyright 2001-2009, David Adams adam+nospam@osnews.com Sun, 22 Nov 2009 04:22:42 GMT http://www.osnews.com/images/osnews.gif http://www.osnews.com http://osnews.com/thread?39599 http://osnews.com/thread?39599 I thought firebird was a web browser.. Mon, 03 Oct 2005 20:25:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread?39609 http://osnews.com/thread?39609 Firebird is the best open source relational database for cross-platform development. Not sure how it compares with postgresql now that postgresql is avaiable in windows as well. Any benchmark available to compared between the two? Mon, 03 Oct 2005 20:47:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread?39634 http://osnews.com/thread?39634 It would indeed be interesting to benchmark the various OS databases: Firebird, Postgres, and MySQL. Mon, 03 Oct 2005 21:31:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread?39661 http://osnews.com/thread?39661 yes and whats really interesting is that firebird comes in several flavours:

1) The superserver is a multithreaded design (much like Mysql) and this is great for raw speed (threads typically being a lot faster to create and considerably more lightweight on memory than seperate processes)

2) The Classic Server. This is a mutli process design like Postgres

3) Embedded - this is a dll or shared object instead of a daemon that you can embed in any application (much like Sqlite)

4) Vulcan - Teh next generation firebird that contains a generic engine that can be any of the above!

I would expect the superserver to be on a par with Mysql for performance but faster than postgres especially with loads of connections due to threads massively outperforming mutliple processes when connection count is high. Mon, 03 Oct 2005 22:22:00 GMT donotreply@osnews.com (Jamie) Comments http://osnews.com/thread?39665 http://osnews.com/thread?39665 I really like Firebird's oracle-mode. Our company is selling a library management system written in Oracle's Dev2000. Getting Oracle sold and installed is always a major hassle. With the Oracle-mode I can concentrate on our own stuff. Mon, 03 Oct 2005 22:30:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread?39668 http://osnews.com/thread?39668 Can you tell us more about this oracle-mode? The docs or url? I am interested. Thank you very much. Mon, 03 Oct 2005 22:41:00 GMT donotreply@osnews.com (adiwibowo) Comments http://osnews.com/thread?39672 http://osnews.com/thread?39672 I don't know if benchmarks would be interesting at all since speed is the one and only strength of MySQL. Fetcher completeness in respect to the SQL standard should be an issue and that's where MySQL sucks. They have a special kind of fetcher creep, the fetcher creeps from one todo list to the next since they can't implement it. Mon, 03 Oct 2005 22:53:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread?39676 http://osnews.com/thread?39676 Oh, never mind.
A little googling found http://www.janus-software.com/fb_fyracle.html.

Seems interesting. Might port our oracle apps to firebird. Mon, 03 Oct 2005 22:56:00 GMT donotreply@osnews.com (adiwibowo) Comments http://osnews.com/thread?39700 http://osnews.com/thread?39700 "Firebird is the best open source relational database for cross-platform development. Not sure how it compares with postgresql now that postgresql is avaiable in windows as well."

Well, you shouldn't say X is the best (or better than Y) if you don't know about Y. :-)

But I've read that Postgres' speed is not so great on Windows. Probably because the Win32 port is new and not much optimization has been done to it.

Haven't seen a major release of Firebird for quite a while now though... Tue, 04 Oct 2005 00:08:00 GMT donotreply@osnews.com (sharyanto) Comments http://osnews.com/thread?39701 http://osnews.com/thread?39701 anybody knows? he's a talented developer and used to hack on FB about 2-4 years ago. Tue, 04 Oct 2005 00:10:00 GMT donotreply@osnews.com (sharyanto) Comments http://osnews.com/thread?39730 http://osnews.com/thread?39730 I'm not interested in how many transactions per second one is over the other (firebird v postgres). I use firebird. all i care for is real MVCC and integrity which both provide. the winner for me is that I can embed firebird by just dropping a dll into the directory my app is in... and i can grow it from embedding to a full server without any pains OR a single change to my code...

choosing either firebird or postgress is a winning scenario for most anyone.... having real MVCC in two free products is just awesome. Tue, 04 Oct 2005 02:52:00 GMT donotreply@osnews.com (_df_) Comments http://osnews.com/thread?39751 http://osnews.com/thread?39751 Is there MVCC that is "not real"?

Mysql+InnoDB also offers MVCC (I believe the "real" one too). Tue, 04 Oct 2005 05:12:00 GMT donotreply@osnews.com (sharyanto) Comments http://osnews.com/thread?39752 http://osnews.com/thread?39752 I don't know if benchmarks would be interesting at all since speed is the one and only strength of MySQL. Fetcher completeness in respect to the SQL standard should be an issue and that's where MySQL sucks. They have a special kind of fetcher creep, the fetcher creeps from one todo list to the next since they can't implement it.

I'm not a big fan of MySQL either, but the upcoming MySQL 5.0 (now beta or just recently RC, I believe) is not so bad. You get strict mode (where MySQL will reject instead of silently accepting/truncating bad dates or out-of-bound strings/numbers). You also get views, triggers, procedural languages, etc. IIRC, MySQL AB has pledged that they will implement "all" parts of the SQL standard. Tue, 04 Oct 2005 05:17:00 GMT donotreply@osnews.com (sharyanto) Comments http://osnews.com/thread?39769 http://osnews.com/thread?39769 Yes, what happened to him? Tue, 04 Oct 2005 06:47:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread?39770 http://osnews.com/thread?39770 AFAIK he is busy working on FB stuff for BroadView Software, a Canadian company with big investment into Firebird, and one from big Firebird & Foundation sponsors. I suppose that he would show up on conference along with others from BroadView. Tue, 04 Oct 2005 07:00:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread?39833 http://osnews.com/thread?39833 Firebird is not that great...
1. Has weird sql dialects
2. Limited number of built in functions
3. Because of small amount of built in functions, you must resort to UDFs that can be flakey.
3.No temp tables at all
4.No tablespaces
5.You can use all SQL in stored procs(except via EXECUTE command)
6. Transactions are stored in the same file as the DB, which results in huge file growth.
7. Because there is no seperate transaction table, you can't do point in time recovery.
8. Only one stored proc language
9. Development is pond water slow...
10. The developer community at times can be cranky(and that is putting it mildly)..
11. Can't do cross server/database queries/joins
12. DBs are referenced by file name and path
13. Password security is limited and weak

When you look close it's a very limited database and these are just a small number of the problems with it.

If you need somthing that can be embedded, then Firebird is a good choice, however it is not ready for the Enterprise yet. Postgresql is a much better choice IMHO. Tue, 04 Oct 2005 13:20:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread?39837 http://osnews.com/thread?39837 >but faster than postgres especially with loads of >connections due to threads massively outperforming >mutliple processes when connection count is high.

This is totally not true. You are forgetting that the Postgresql process is created at connection time and has nothing to do with the speed of queries.
Also with Postgres (and classic FB) one errant thread wont take down the whole server.(it will in SS firebird)
You also seem to be forgetting that with lots of threads you get lots of context swaps which can hurt performance.
The processes used by PG and FB classic will handle more connections better than threads, espesially on Unix systems.

I can tell you this for sure, when the postgres.conf file is setup properly it is just as fast if not faster than firebird. Tue, 04 Oct 2005 13:30:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread?39839 http://osnews.com/thread?39839 I believe he got pissed off at Jim Starkey.
Jim can be a huge ahole, actually he is most of the time. Tue, 04 Oct 2005 13:33:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread?39868 http://osnews.com/thread?39868 Most of your points are valid specially numbers 6 and 9.

But some others are kinda innacurated like

Number 1.- I think the dialect is plaint simple.
Number 3.- Is coming in firebird 2 before at the end of this year.
Number 4.- Is that really necesary?
Number 12.- There are alias for them so you dont have to use the path.
number 13.- Your DB will be as secure as you secure your server.

And you forgot one, the documentation is to poor.

But mean while PG in windows keep being to damn slow I will have no choice. Tue, 04 Oct 2005 14:17:00 GMT donotreply@osnews.com (Manuma) Comments http://osnews.com/thread?39893 http://osnews.com/thread?39893 1. It's historical, and all DB products have their SQL quirks don't they?

2 & 3 should not be a problem if FB comes prepackaged with the frequently used functions.

8. Most other SQL DBs have one stored procedure language either, and that doesn't seem to be too crippling. But I admit, being able to use Ruby (e.g. in Postgre) or .NET (e.g. in SQL Server) should be fun and joyful compared to those weird, COBOL-like procedure languages.

9 & 10. This is one of the main problem with FB.

12. Aliases.

---

My main problem with FB is that DDL (CREATE TABLE, ALTER TABLE, DROP TABLE, etc) are weird and not really transactional. You need to COMMIT after each DDL. Well sometimes there are use cases where I need DDL to be inside a transaction so it is rollback-able if things go wrong.

---

But as long as there's no embedded Postgres (which will be the case for a long time) FB will have its niche. SQLite doesn't come close in feature set. Tue, 04 Oct 2005 15:05:00 GMT donotreply@osnews.com (sharyanto) Comments http://osnews.com/thread?39905 http://osnews.com/thread?39905 "speed is the one and only strength of MySQL"

Only if you turn off transactions in mySQL. Using InnoDB engine with mySQL is dog slow. We have done lots of benchmarks of Firebird and mySQL (InnoDB) and Firebird wins out easily. Only time I have ever seen mySQL beat Firebird is when mySQL is using non-transactal myISAM, and the queries are very simple (no joins etc...), but why test this way? Only the simplest of apps would not need transactions or joins. Tue, 04 Oct 2005 15:22:00 GMT donotreply@osnews.com (Matt Giacomini) Comments http://osnews.com/thread?39907 http://osnews.com/thread?39907 As long as you don't mind paying for it, or open sourcing any application that touches it.

I'm referring to the fact that mySQL 5 no longer has an LGPL driver. Tue, 04 Oct 2005 15:25:00 GMT donotreply@osnews.com (Matt Giacomini) Comments http://osnews.com/thread?39985 http://osnews.com/thread?39985 Multiple process DBs like Postgres are not scalable when compared to threading ones like Firebird and mysql.

Threaded ones can easily support 10x and even 20x the no of connections of a process based one (due to lighter memory requirements).

The cache is shared amongst all threads hence hotter cache and faster queries.

So I am right - threaded RDBMS easily out perform process based ones when the no of conections exceed about a dozen. Tue, 04 Oct 2005 17:50:00 GMT donotreply@osnews.com (Jamie) Comments http://osnews.com/thread?40118 http://osnews.com/thread?40118 > 1. Has weird sql dialects

The only quirky thing about Firebird is the Stored Proc language - this is NOT part of the SQL dialect, and all comparable products have similar quirks (e.g. T-SQL in SQL Server and Oracle's PLSQL which is basically ADA.)

> 2. Limited number of built in functions
> 3. Because of small amount of built in functions,
> you must resort to UDFs that can be flakey.

UDF, UDF, UDF. Regression testing. I have written countless UDF functions for Interbase, and it aint hard. In fact, it is so easy as to be stupidly easy.

If you test your code, you have nothing to worry about!!

> 3.No temp tables at all

Who needs temp tables? What are they used for?

create procedure NOTEMPTABLENEEDED
returns (id integer, text varchar (20), num integer)
declare variable t1 varchar (7);
declare variable t2 varchar (10);
begin
for select id, text1, text2, num
from atable
into :id, :t1, :t2, :num do
begin
text = :t1 || :t2;
suspend;
end
end

then:

select * from NOTEMPTABLENEEDED;

TADA! No temp table needed.


> 4.No tablespaces

Explain why that is a problem?

> 5.You can use all SQL in stored procs(except via
> EXECUTE command)

That doesn't even make any sense. You can call "execute procedure" or you can call "select whatever from..." depending on whether the SP returns one result or multiple lines. What is the problem with that?

> 6. Transactions are stored in the same file as the
> DB, which results in huge file growth.

Which can be removed instantly if you back up and restore the database... you do backup your database periodically, dont you?

gbak -b mydatabase.gdb mydatabase.gbk -user XXX - pass YYY

gbak -r mydatabase.gbk mydatabase.gdb -user XXX - pass YYY

Will recover all surplus space.


> 7. Because there is no seperate transaction table,
> you can't do point in time recovery.

And why is that an issue? Do regular backups (which can be done inline whilst the database is being used and accessed) and this is purely moot.

> 8. Only one stored proc language

LOL. SQL Server 7 and 2000 only had one too.

> 9. Development is pond water slow...

Rather it was stable.

> 10. The developer community at times can be cranky
> (and that is putting it mildly)..

Because they complained when someone stole their name? What would you do?

> 11. Can't do cross server/database queries/joins

Good. Maybe then people will design better systems.

> 12. DBs are referenced by file name and path

Un true. Interbase, and by virtue Firebird up to at least 1.5, supports 4 different access methods. Local (by path), TCP/IP, SPX/IPX and Named Pipe.

Equally, you can pump either of the following paths into a Windows Firebird TCP-IP connection:

127.0.0.1:c:mydatadata.gdb
127.0.0.1:/mydata/data.gdb

either will work.

> 13. Password security is limited and weak

Why? How secure is your server? You do not have to use the default admin user, in fact we used to delete that user when I worked for a company that used FB1.5 a while back.

> When you look close it's a very limited database and
> these are just a small number of the problems with
> it.

You can always bet this post will arrive on OS News when there is a Firebird story. YAWN!

> If you need somthing that can be embedded, then
> Firebird is a good choice, however it is not ready
> for the Enterprise yet. Postgresql is a much better
> choice IMHO.

Oh crap, well we better let all out customers know.... Seriously, you are spouting complete rubbish. Tue, 04 Oct 2005 22:21:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread?40179 http://osnews.com/thread?40179 I don't think so, I have used Firebird and Postgresql and Postgres is the better database.




It makes perfect sense, because in Postgresql stored procs you dont' have to use EXECUTE, you can simply call CREATE USER or CREATE DATABASE or anything you want, no need to use execute at all, and that's because Postgresql only has one SQL, Firebird has PSQL, DSQL and one other one, you can only use PSQL in procs, if you want to execute DDL you must use execute. Wed, 05 Oct 2005 00:17:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread?40188 http://osnews.com/thread?40188 > 12. DBs are referenced by file name and path

Un true. Interbase, and by virtue Firebird up to at least 1.5, supports 4 different access methods. Local (by path), TCP/IP, SPX/IPX and Named Pipe. >

true true true, using TCP/IP you must use like so:

192.168.12.13:/opt/data/mytestdb.fdb NOTE THE PATH is still used, no mater what transport you use the path must be included.

Even with aliases you must manually build them on the server side. You don't have to do any of this with Postgresql, the more you use PG, the more you wonder why you used to like FB.
PG keeps a system table called pg_database and it contains info on all databases created. With PG all you need is the name, the rest is taken care of.

As far a security goes Postgres has built in SSL support, encrypted/md5 passwords and access control via host/IP.

Also as far win32 speed goes, I ported a Firebird app to Postgresql and we can't tell the difference, it was fast before and it is fast now with Postgres.
Postgres out of the box is not optimized for high end corp systems because most people don't have a 3.5gzh Xeon, so you have to tweak the conf file a bit to get really good performance, it's just part of the flexiblitiy. Wed, 05 Oct 2005 00:55:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread?40298 http://osnews.com/thread?40298 >Even with aliases you must manually build them on the
> server side. You don't have to do any of this with
> Postgresql, the more you use PG, the more you wonder
> why you used to like FB.
> PG keeps a system table called pg_database and it
> contains info on all databases created. With PG all you
> need is the name, the rest is taken care of.

I prefer the FB way, it's far better than central dictionary in system table. I frequently have many copies of the same database with different data and structures (some apps. work that way, sometimes is just for development). Handling that in PG is very painful (each must have different name etc.), while in FB I don't even think about it, just type in the right path and go. When I need db location independence (only on deployment), I can set up aliases, which is very simple. The fact that under FB, databases are selfcontained, easily transportable beasts is a great advantage over such behemoths like PG, that have many unnecessary layers of complexity, that add to the cost of db management. While PG has some nice features, it carry too many "database stone age" design flaws.

> As far a security goes Postgres has built in SSL
> support, encrypted/md5 passwords and access control
> via host/IP.

I don't need that at the db server, because I can easily do that by other means when necessary (ZeBeDe etc.), so my server will not carry along a dead weight when I don't need it. Wed, 05 Oct 2005 08:27:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread?42158 http://osnews.com/thread?42158 um..wrong. The only time you use execute procedure is when you want to *run* a procedure. As previously noted, you don't even need to do that if your procedure calls suspend after it has filled the returned variables - you can just call it as if it was a built in function via select. Sun, 09 Oct 2005 12:39:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread?44046 http://osnews.com/thread?44046 How many people will still come because they think it's about Firefox. Wed, 12 Oct 2005 18:46:00 GMT donotreply@osnews.com (Anonymous) Comments