Firebird will not block readers if some process is writting which, as you say, is 
common and it will only block writters that are modifying the same row.  However it 
has a really neat feature that while you are in a transaction you are guaranteed that 
the data won't change on you.  So if you are busy going some stuff and someone commits 
some changes you won't see it until you end your current transaction.  Hopefully I 
explained it ok.

I wasn't saying the postgres didn't have the features I listed.  I know it is a very 
serious DB platform.  I just am finding that Firebird agrees with me a bit more.

My one complaint is the general confusion regarding documentation and the slowness of 
releases.  I really am looking forward to some of the features added in 1.5 but who 
knows when that will come out.

Classic server runs from inetd which I'm not really a fan of.  Super server is it's 
own server which means it's a bit snappier and it adds support for remote management.

I believe they have some complete JDBC drivers that are supposedly quite stable.  I 
think there are a few different sets though from different vendors so who knows.

What is ACID compliance?

Jeff

On Thu, Oct 24, 2002 at 10:40:03AM -0600, Aaron J. Seigo wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Thursday 24 October 2002 09:33, [EMAIL PROTECTED] wrote:
> > Hey All,
> >
> > I am wondering if anyone has
> > experience / thoughts on Interbase / Firebird (firebird.sourceforge.net). 
> 
> i've talked with others who have run it and have heard generally good things 
> about it. i have actually used it myself as i already have a Free ACID 
> compliant database ;-)
> 
> >   I've been using it a bit lately
> > and so far prefer it to either of MySQL or Postgresql for several reasons:
> 
> most of these features you list are not unique to firebird.
> 
> these are found in postgresql's resume:
> 
> > 2) supports a very complete (AFIAK) SQL command set
> >  3) very easy to setup and administer
> >  4) supports run-time backups
> >  7) good trackrecord.
> > 9) interfaces with Java, Python, Ruby, PHP, C, ... quite well
> >  10) stored procedures, triggers and other handy things
> >  11) extensible through UDFs (User Defined Functions), calls to native
> > libraries 
> > 12) domains are really, really cool
> >  14) killer feature: quite cross plaftorm, runs happily on windows, linux,
> > various unixes, ...  (I hate it when apps require on platform or another :)
> 
> some comments on these:
> 
> >  8) quick recovery from crashes (usually fraction of a second) used in U.S.
> > mil tanks for this reason
> 
> pgsql recovers quickly, especially since it uses a controller/backend model a 
> crash in one backend doesn't bring the entire system down.  your next 
> connection will be handled by the next backend (or a new one if none were 
> available). if the postmaster were to crash (something i've never seen 
> happen, even during the crash happy days of 6.5 and before), start up time 
> seems to depend on database size.
> 
> >  13) small memory footprint (2M kernel, 10M for full system with client)
> 
>  VSZ     RSS   COMMAND
>  12460  156    /usr/local/pgsql/bin/postmaster
>  13452  52     postgres: stats buffer process
> 12496  172    postgres: stats collector process
> 12920  3248  postgres: postgres lizard [local] idle
> 
> of course, if you want to save the 224k, you can turn off the stats 
> collectors... of course, this is largely irrelevant for all but embedded 
> databases, in which case you'll probalby be using a different sort of 
> solution altogether. the vast majority of memory usage in a production SQL 
> database comes in the form of buffers for indexes, queries and results.
> 
> >  6) consistent reads
> 
> do you mean consistent as in "writers don't block readers, so all reads are 
> consistent tie-wise regardless of other activity"? if so, that's a pretty 
> common thing among quality databases these days. i don't know if pgsql 
> _guarentees_ constant time reads, but writers don't block readers which is 
> the big winner here. the only other hitch i can know of is that doing an 
> analyze after a lot of writes in pgsql can increase complex query speed.
> 
> >  1) has some very good commercial and free administration tools (some with
> > GUI) that make it easy to get started.
> 
> MySQL and pgsql both have GUI admin tools you can get, but both tend to be 
> extremely low admin-overhead type dbs. firebird does have nicer GUI tools, 
> but then so does IIS over Apache ;-)
> 
> >  5) database shadows
> 
> this is really the only advantage that i know of. replication is lacking in 
> both MySQL and PostgreSQL. there are ways to hack it in, but they are all 
> chewing-gum-and-baling-wire type stunts. firebird's shadows are a step up 
> indeed; btw, are they read-only (e.g. master->slave type replication), 
> read-write (peered replication) or hidden (hot-backup only)?
> 
> some other observations / questions:
> 
>  o which is better: their classic or "super" server?
> 
>  o it's really hard to get a grasp on what they are doing developmentally on 
> the server. their email lists are all over the place, with hard to get to 
> archives (if any) and many of them are on yahoogroups =/ an open development 
> line is important to me.
> 
>  o the license it is under is unique, complex and GPL incompatible. according 
> to the FSF it is similar in intent and allowances as the MPL. too bad they 
> had to go create Yet Another License. 
> 
>  o windows seems to be the preffered platform? while i see alpha releases of 
> v1.5 for windows, i see nothing for the other platforms. is this because the 
> devels work on windows? or because those on windows can't build the source as 
> easily (so those on Linux are just expected to track CVS for alpha/betas?)?
> 
>  o are the JDBC drivers complete? i only see RC1 downloads available for JDBC
> 
>  o what is the devel pace like? i notice they had the initial release at the 
> end of 2000, hit betas in late summer of 2001, and a final release in the 
> Spring of 2002. what took a over a year to develop exactly?
> 
>  o what are they working on? features? important bug fixes? etc...
> 
> - -- 
> Aaron J. Seigo
> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
> 
> "Everything should be made as simple as possible, but not simpler"
>     - Albert Einstein
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.7 (GNU/Linux)
> 
> iD8DBQE9uCJj1rcusafx20MRAlhyAJ40vmUUTMTzwIRAht85QKSpATxAMgCgqsR1
> lumYyA4x5tdEy0XMEst6FnQ=
> =mK5e
> -----END PGP SIGNATURE-----
> 

Reply via email to