Hello:

In my old Delphi days I worked with interbase and later with firebird. (Now MySQL and MsSQLserver, life is hard)

I have some complains, but the overall feeling about Firebird is very positive. It is a handy and powerful enough for almost everything . In fact, I still have some production server running with no problems for years.

I have tried a little PostgreSQL, it looks powerful and has good reviews and has features that firebird hasn't, some of them very interesting like replication. Nevertheless, I've heard that windows is not its natural habitat. On the other hand, Firebrid looks very handy for pet projects (and not so pet)

Any opinion? what do you use?.

Com'on  troll and flame a little ;-)

Santiago A. wrote

I have some complains, but the overall feeling about Firebird is very positive. It is a handy and powerful enough for almost everything . In fact, I still have some production server running with no problems for years.

I've used Firebird for the last 10 years in various companies. Databases ranged from 100's of MBytes to multi TeraByte databases. The latter contains lots of data, not necessarily tons of binary blob data. Firebird performed brilliantly throughout the various projects I used it in. I simply can't fault the database server. The fact that it is so easy to install, maintain, backup and even use in read-only or embedded environments is a massive plus point.

Oh, and I've access Firebird from Free Pascal, Delphi and Java based projects - all with equal ease.

I have tried a little PostgreSQL, it looks powerful and has good reviews and has features that firebird hasn't, some of them very interesting like replication.

I have heard good things about PostgreSQL too, and once installed it under Linux, but never really used it. I did do a couple of speed tests (that could run under various RDBMS's) and PostgreSQL did not perform very well out-of-the-box. Apparently you need to tweak it first before it performs decently. But this was some 6 years ago, so I don't know if things have improved since. I do know PostgreSQL does have some Enterprise style features like replication - not sure if there is anything else included too.

Nevertheless, I've heard that windows is not its natural habitat.

I have heard the same, but never tried PostgreSQL under Windows. I have run Firebird under Windows, Linux and FreeBSD with great results.

Apparently Embarcadero's Interbase database is pretty terrible - I've only heard bad things about it. And no Firebird and Interbase don't have common code any more. Firebird was totally rewritten pretty soon after the original Interbase code was released. Yet the network protocol and API's was kept the same for compatibility. Speaking of network protocols. Apparently the latest Firebird has a very much improved protocol that gives a much higher network throughput - I personally haven't tested it yet.

Comparing Firebird to MySQL.... All I can say is I really don't know why Firebird isn't more popular - it is brilliant. MySQL on the other hand is absolutely ridiculous!!! I explained all my reasons many times before in the Lazarus Forums (eg: One simply example is MySQL's reliance on the file system it is installed on and that can (and does) determine if the database table names are case sensitive or not. So don't ever move from a Windows MySQL install to a Linux MySQL install - you'll shouldn't be surprised if your applications stop working).

Anyway, I also like the fact that Firebird databases are really compact compared to SQL-Server or PostgreSQL databases which contain the exact same structure and data. Some will argue the opposite fact though.

Regards,
Graeme

We use PostgreSQL, with heavy emphasis on its transaction handling etc.

In general it works out of the box, and its documentation etc. is fairly easy to manage... I use Firebird for some small-scale stuff and found locating instructions for even simple jobs to be a challenge.

Well, I never reached that point. My databases were from 100 Mb to less than 2 Gb.

Comparing Firebird to MySQL.... All I can say is I really don't know why Firebird isn't more popular

That's my point. Why Firebird is not more popular?

Once I read two point about Firebird lack of popularity:
* In early days, firebird documentation was almost inexistent, there were a few .txt with new features but you had to rely on Interbase 6.0 docs, that weren't very good either. So it looked like an almost abandoned software maintained by a few fans.
* It had no administration tool, you had (and you still have) to rely on third part tools. I think flamerobin is the administration tool "de facto"

PostgreSQL is more complete, but more complex as well. Nevertheless I think Firebird does what 99% non-big-enterprise projects need, and works perfectly in windows, Linux and other unices.
First time I heard about postgreSQL, it looked more a laboratory test-tool to experiment with new academic advanced features than a production RDBM. Compared to Firebird, Firebird looked more robust and more aimed to real world.
Since then, postgreSQL has become the new darling RDBM in opensource  world. I was wondering if firebird has some evident drawback , that I can't see. or it is years behind PostgresSQL.
Am I missing important things?

MySQL on the other hand is absolutely ridiculous!!!

MySQL was a low fingerprint for web servers. It even hadn't transactions. When it appeared it was almost the only one. Since then it has evolved to a more complete RDBM, but...

In our previous episode, Santiago A. said:

* it was x86 only for a long time.

Which is why I ended up with postgresql, having powerpc and later arm servers.

Marco van de Voort wrote

In our previous episode, Santiago A. said:> That's my point. Why Firebird is not more popular?> > Once I read two point about Firebird lack of popularity:> * In early days, firebird documentation was almost inexistent, there> were a few .txt with new features but you had to rely on Interbase 6.0> docs, that weren't very good either. So it looked like an almost> abandoned software maintained by a few fans.> * It had no administration tool, you had (and you still have) to rely on> third part tools. I think flamerobin is the administration tool "de facto" * it was x86 only for a long time. Which is why I ended up with postgresql, having powerpc and later armservers.

One further point if I may. PostgreSQL and Firebird both have the capability of sending asynchronous notifications to clients, i.e. along the lines of "somebody's changed this table, everybody needs to check it". When I last looked, they were the only free databases that did this, although in the case of something strictly single-user like SQLite the facility isn't really needed.

Provided that you're not getting into things like creating new users on the fly, the SQL dialects are sufficiently similar that a client program can talk to either without substantial modification. I think that a reasonable approach is to select Postgres for departmental or larger storage, or Firebird for something that's strictly local.

Why Postgres is better for "departmental or larger storage"? What has Postgres that Firebird hasn't?

I have some complains about firebird.

i.e. Can't alter views, they must be deleted an recreated.

I had made backups that couldn't be restored  because wrong data.  I don't know it happened, maybe a change in constraints that didn't check former valid data, but with new constraint invalid. But the overall is that It allowed in some point invalid data, to  backup it, but not to restore it.

But that was versions ago, I've heard it those problems where solved.

So, again, what has Postgres that Firebird hasn't? I have worked with firebird a lot, but not with Postgres, it will be interesting a review of someone who has worked with both.

PS: Sorry Mark, I replied to you, not to the group. ;-)

Santiago A. wrote

So, again, what has Postgres that Firebird hasn't? I have worked with firebird a lot, but not with Postgres, it will be interesting a review of someone who has worked with both.

Aggressively-tested compliance with SQL "correctness", including regression testing as standard. Transactional robustness, which is something they had a /long/ time before the competition. A rich palette of data types, character sets, timezones etc., and predefined functions to manipulate them. Analytic windowing functions, replication, connection pooling and so on. Fairly extensive third-party extensions for GIS, statistical etc. support. And that's just from memory, without referring to any advocacy documents.

Decent documentation in one place, which is something that I found to be a particular issue with Firebird when I looked at it perhaps four years ago. https://www.postgresql.org/

Mark Morgan Lloyd wrote

I think that a reasonable approach is to select Postgres for departmental or larger storage, or Firebird for something that's strictly local.

Once again... why must Firebird always be reduced to the “only for smaller database needs” environments?

That is exactly the point I was trying to make with my earlier reply. I’ve used Firebird in very busy production (Enterprise) environments with large amounts of users hitting the database server, and with large sets of data stored. Firebird performed fantastically well. So I really don’t see the need to reduce Firebird to only “smallish” environments. Firebird is a very well rounded database server, and the latest version introduces so very welcomed new features.

What Firebird is lacking is a really good "management studio" style application. FlameRobin is currently filling that space, but I definitely see space for improvement (tracing and profiling, some graphs explaining the results, graphical execution plans of queries etc). Maybe this is a good business opportunely for somebody to venture into.

Regards,
Graeme

Santiago A. wrote

Why Postgres is better for "departmental or larger storage"? What has Postgres that Firebird hasn't?

Exactly. In my years of using Firebird, I think it is a perfect fit for small and large environments.

Regards,
Graeme

Let me put it this way Graeme. I've suggested that different servers have different areas of applicability, I've not gone out of my way to rubbish any of them. Now I'm sorry if I've startled one of your holy cows, but right now I've got my own problems and I don't see spending time correlating performance figures to counter one of your arguments- for which I'm sure I'd get minimal gratitude from your direction at least- as one of them.

If /you/ don't like the fairly inclusive and tolerant position that I laid out, then I suggest it's incumbent on /you/ to put together performance figures etc., and then I'd suggest that /you/ set them out on one of the PostgreSQL mailing lists asking for comments and refutation.

Because you might be surprised, but I think you'd find that you'd get a more courteous hearing than you're usually prepared to accord anybody around here who disagrees with you.

Mark Morgan Lloyd wrote

I've suggested that different servers have different areas of applicability,

I better mention that I replied before I saw your list of reasons for using PostgreSQL. Apologies if I upset you. Chill please - no "holly war" was intended.

Regards,
Graeme

No, that's fine and I'm sorry for having escalated things in that case.

One of the (numerous) things I'm wrestling with at the moment is PostgreSQL replication... there's more than one way to do it, and- unusually- the documentation isn't entirely clear. I find the the link below has a considerable amount of useful stuff in it, but apart from that there's the "explain" facility etc. that's useful once one's actually using Postgres, plus a lot of scope for tweaking parameters.

https://en.wikibooks.org/wiki/PostgreSQL

The PostgreSQL developers do appear to be going "balls out" to challenge Oracle, with a number of companies offering paid support etc.

Mark Morgan Lloyd wrote

One of the (numerous) things I'm wrestling with at the moment is PostgreSQL replication...

Speaking of PostgreSQL, I just realised that tiOPF’s 3-hourly unit test runs don’t include tests against PostgreSQL. I’m busy setting that up now.

This morning I read through some PostgreSQL documentation, and some of the SQL syntax is pretty nice. I do curse the fact that they too (like Microsoft SQL Server) supports XML field types. I so *hate* the usage of two companies I’ve now seen the XML field types being used as the “lets dump everything in there because we are too fucken lazy to implement real database design”. It is so hard to find information when they are hidden in XML fields, and also makes SQL queries 10x harder. Obviously it also means your application is not portable to other relation database servers. Vendor lock-in yet again! I curse the person that came up with the XML field data type concept!!

Regards,
Graeme

Mark Morgan Lloyd wrote

rubbish any of them. Now I'm sorry if I've startled one of your holy cows, but right now I've got my own problems and I don't see spending

*rofl* I'm going to file that right next to "sacred cow tipping". :D

g.

of commonality between PostgreSQL and Firebird syntax in the couple of places I was trying to use them in parallel, but I wasn't trying to do a lot of e.g. date arithmetic. Postgres had the edge when it came to things like setting up a new user under program control with a specific date validity (e.g. good for 24 hours only), and also when trying to find out whether a user was already known, what the system was doing (e.g. current connection's server process PID) and so on.

Both have notification functions which are important to me, I think I had to use the library API on FB to send a message while Postgres could do that from SQL (intended to be used as part of a trigger). Postgres's documentation was better, with FB I found myself having to use several Borland-era PDF manuals.

When I've got my B5500 emulator running I might use SQLite for an internal symbol table (basically, to allow the emulator to debug the operating system) but I've not got any odd jobs which would allow me to run all three databases in parallel.

I've never touched MySQL, since when we had to make a choice it didn't have transaction handling and we were planning to put it on a customer site... and knowing that they were a big DB2 user the name in itself quite simply sounded too tacky to be taken seriously. Obviously 20 years on it's got a bit more street cred :-)

I think you should ask the question "which database is best for my project". The selection of database should depend on the assumptions and requirements of your project. For some projects you only need SQLite. But for another project you will need Oracle. And in another you will be doomed to what your customer already has.

W dniu 2017-10-25 o 19:22, Santiago A. pisze: