Subject | Re: Firebird performance |
---|---|
Author | fabiano_bonin <fabiano@leonilda.com.br> |
Post date | 2003-02-26T13:22:15Z |
Paul, i am a developer from Brazil, and some months ago i migrated
all my apps from SQL Server to Firebird (first to Interbase 6, than
to Firebird).
I did it after lots of performance tests, and after considering all
the technical aspects of both servers.
In some speed tests i made, like 'select count(*) from table', the
winner always was SQL Server, but in the tests simulating a
production environment, with queries like 'select * from table where
table.id = :id', where you are interested in a partial set of the
data, the winner was always firebird.
There are some bugs in the Firebird 1.0, some serious in my point of
view, but i had to learn how to live with them. BUT, all bugs that i
knew were solved in Firebird 1.5, and the overall performance was
greatly inproved, too.
Firebird 1.0 also didn't have some commands available in SQL Server
that was very usefull to developers, like ISNULL, CASE ... THEN, and
features like server-side aliases and others, but they was
implemented in Firebird 1.5, too.
About performance, i can say: don't worry. FB will do the job for
you.
Now i am sure that i made the right choice, because FB meet all my
requirements. I am not missing SQL Server anyway. FB is easier to
install, to maintain, to port to other computers and platforms, you
can follow it's development and if you suggest something the
developers will hear you, it's becoming better each day, it's light,
it's free. Is this what happens with Microsoft???
--- In ib-support@yahoogroups.com, "paul_damian <paul_damian@y...>"
<paul_damian@y...> wrote:
all my apps from SQL Server to Firebird (first to Interbase 6, than
to Firebird).
I did it after lots of performance tests, and after considering all
the technical aspects of both servers.
In some speed tests i made, like 'select count(*) from table', the
winner always was SQL Server, but in the tests simulating a
production environment, with queries like 'select * from table where
table.id = :id', where you are interested in a partial set of the
data, the winner was always firebird.
There are some bugs in the Firebird 1.0, some serious in my point of
view, but i had to learn how to live with them. BUT, all bugs that i
knew were solved in Firebird 1.5, and the overall performance was
greatly inproved, too.
Firebird 1.0 also didn't have some commands available in SQL Server
that was very usefull to developers, like ISNULL, CASE ... THEN, and
features like server-side aliases and others, but they was
implemented in Firebird 1.5, too.
About performance, i can say: don't worry. FB will do the job for
you.
Now i am sure that i made the right choice, because FB meet all my
requirements. I am not missing SQL Server anyway. FB is easier to
install, to maintain, to port to other computers and platforms, you
can follow it's development and if you suggest something the
developers will hear you, it's becoming better each day, it's light,
it's free. Is this what happens with Microsoft???
--- In ib-support@yahoogroups.com, "paul_damian <paul_damian@y...>"
<paul_damian@y...> wrote:
> Hello all!you
>
> I've discovered Firebird a couple of months ago. And I consider it
> for switching from MS-SQL Server, because of the price. And I ask
> to tell me about your experience implementing Firebird, regardingthe
> performance.W2K
>
> My app is designed for a small corporate intranet (most 5 users
> logged in simontaneously), the network is running W98 / W2K prof
> clients and TCP/IP. Firebird will be installed as service on an
> Professional machine (planned as Pentium IV / 1.8G, 256MB, RAIDHDD
> 40MB). Even if it sounds not bad, I'm concerned about thefollowing:
> at some time it could happen that all clients will connect to anit?
> table, wanting to "pump" thousends of records, some of them out
> (SELECT FROM) and some of them in (INSERT TO). Will Firebird do
> Will it be reliable?me
>
> Any advice you can give me? Perhaps also encouraging me, telling
> from your experience Firebird doing more than that? :-)
>
> Best regards,
> Paul