Re: PostgreSQL vs Firebird SQL

Em 10/02/2016 13:32, Andy Colson escreveu:
> On 2/9/2016 10:10 PM, ioan ghip wrote:
>> I have a Firebird SQL database running on one of my servers which has
>> about 50k inserts, about 100k updates and about 30k deletes every day.
>> There are about 4 million records in 24 tables. I have a bunch of stored
>> procedures, triggers, events and views that I'm using.
>> Firebird works fairly well, but from time to time the database gets
>> corrupted and I couldn't figure out yet (after many years of running)
>> what's the reason. When this happens I run "gfix -mend -full -ignore",
>> backup and restore the db and everything is fine until next problem in a
>> week, or a month.
>>
>> I never used PostgreSQL. Yesterday I installed it on my development
>> machine and after few tests I saw that it's fairly easy to use.
>>
>> Does anyone have experience with both, Firebird and PostgreSQL? Is
>> PostgreSQL way better performing than Firebird? Is it worth the effort
>> moving away from Firebird? Would I gain stability and increased
>> performance?
>>
>> Thanks.
>>
>
>
> One of our windows apps runs on a client/server setup in the office,
> and then on laptop for remote use.  We use Firebird (FB) for both.
> Its a quick simple install, runs in 8 meg of ram, has zero maintenance.
>
> The only time I've seen corruptions is anti-virus scanning the db, and
> HD/raid problems.
>
> FB is a nice little db.  That said, I can wholeheartedly recommend PG!
> It could still run on a laptop, might require a bit more maintenance,
> but on a dedicated server, it would be able to grow and use all the
> resources available.
>
> If you have HD/raid problems, then you wont gain stability. Upgrading
> between major versions is also more difficult.
>
> That said, yes, you'd gain stability and performance, and not only
> that, a huge amount of functionality.  A Huge Amount!
>
> FB has, replace() for string ops, oh and substring().  Baa. That's
> nothing compared to PG's.  Its like that Aladdin song 'a whole new
> world'!
>
> You know, in FB, when one person does a large delete on a table? The
> next person that runs a select will perform the vacuum on it. Its the
> person running the select that pays the time for a huge delete.  In
> PG, there is a background vacuum task, so users don't pay the price.
>
> Respect for FB, but my heart belongs to PG.
>
> -Andy
>
>
+1

Also, running a office server, being it small or huge, you can have a
replicated server - so it is virtually impossible to loose data.

Synchronous and asynchronous replication is really easy to implement in
PG, and makes it a strong (in terms of lossless) database server - even
when compared with Oracle, MS SQL or IBM Db2. You can have two database
servers, being one updatable and two for queries - that make reporting
faster, for example!

By using BARMAN you can have online incremental backups to a third
server, which a unvaluable for online transaction and operation. You may
never ever loose data again - except if you database server crashes
(hardware failure), and your replicated server crashes at same time
(hardware failure also), and then you may loose up to last 15Mb of
changes (the amount of data transfered to backup server on each
incremental step).

So if your concern if for safety: keep your servers geografically
separated, or, at minimum, in different eletrical and network
installations, preferable in different buildings, using good hardware
(with twins disks, power lines, network interfaces - all doubled).
Personally, I do like Dell R420 servers for database servers - they are
really reliable in my setup.

Finally, you can have embed database running togheter with your app -
and even the for said additional maintenance, you can schedule it or
even throw from inside your app.

You will see it is possible to have a 99.999% database uptime with no
hasless, running for years without aditional DBA interference.

Also, the tooling to help planning indices and test query performance is
really good, and the PgAdmin III has been good and quite strong (has
some flaws, but nothing that really interfere in its usage).


Regards,

Edson Richter