Hello,

> Let me share some thoughts which are not related with email below, but
> inspired by it (as a consequence of long time thoughts and overview of
> our experience)
>
> First, I need to say that many IT managers and developers suffer from
> the "try to use a bigger gun" inferiority complex (for those who don't
> remember/don't know - in old Quake/Unreal when your player was killed by
> bot (computer), it gave sarcastic advice: "Try to use a bigger gun").
> In our current world, when we decide what to choose it usually means
> "what to buy", and there is pretty stable dependency between price and
> quality - choosing more expensive car will give you more horse power and
> luxury options, for example.
> From this point of view even the first look at MSSQL total cost of
> ownership (licenses, hardware requirement, personnel costs) promises
> huge advantage over free Firebird.
> To give the idea for those who is not aware - end-user cost will be
> increased by MSSQL license (+Windows Server license), which is ~$7000
> USD/processor for MSSQL Standard and ~26000/CPU for Enterprise. Is this
> not a bigger gun? :)

I fully agree, but what we saw when talking to companies, mainly in DWH
projects, that the entire tool stack of SQL Server, even with the
Standard Edition, is very attractive for the price compared to other
commercial products or even with a combination of open source RDBMS and
some independent DWH/BI product like Pentaho, Jasper etc.

I would use Firebird as a relational backend whenever I can, but as an
entire tool stack, SQL Server is very competitive to open source products.

In another project I have been involved was to reduce licensing cost of
their Oracle environment, as from history, they had quite a number of
Enterprise Edition running and Oracle is famous to change license
agreements. Sure, also open source RDBMS was a topic, but finally, as
they are running a VERY critical business with a loss in the millions
USD for an outage for a few hours, they simply need a solution where
they can put pressure on it, if something fails from a DBMS POV,
including support at their site within hours etc.

IMHO Firebird is doing very well for deployments where people have no
ideas about a DBMS or where people aren't using another RDBMS in their
company yet. It's usually hard to convince people if they have an IT
apartment, hosting already SQL Server, having knowledge for the product etc.

> Second, level of many developers is not sufficient to build efficient
> applications at Firebird, though their ego is big enough to claim
> Firebird "slow". Yesterday I spent 2 hour optimizing close-sourced
> application which was very slow with 1.5Gb database... simply because
> developers did not create several indices and also massively used SELECT
> DISTINCT to extract dictionaries (Zip codes) from the main table (1.5Mln
> records) instead of using separate tables. Luckily we have FBScanner to
> audit their ugly queries... though many things cannot be fixed.
> Bad developers (or, optionally, inexperienced guys) are always in place,
> and since there is no developers certification (as well as massive
> training courses), we will always see those who barely have read
> several chapters from Quick Start guide and shifted responsibility to
> Firebird.

I fully agree. The last few consulting stuff was mainly about
performance issues with Firebird, which basically resulted in:

- No tuning of the Firebird server in respect to RAM usage, header page
settings, etc. at all
- The developer had no idea what he was actually doing although not with
FBScanner but with another product *g*. TABLE STABILITY isolation level,
commit retaining behind the scence, read committed with no record
version etc. A lot of weird things. That stuff would have bring SQL
Server down as well, especially when it comes to concurrency control,
because SQL Server doesn't have MVCC enabled per default. Giving them a
basic class in 2 days about writing Firebird client applications sorted
things out pretty quickly and are happy campers for a few weeks now.

> Third, there is "career" problem for IT managers. At the conference in
> Luxembourg I heard a story which illustrates the problem: one
> Firebird-company has won a tender over SAP and, after some time,
> successfully deployed Firebird-based system at customer's site, and it
> was a small party to celebrate its launch. After drinking some beers
> customer's CIO told that this deployment ruined his career: "If we would
> have a SAP, I can put in my CV line "Successful SAP deployment" and my
> next job would be some bank or Fortune-2000, and what I will write now?
> Firebird-based system?".
> This is a great temptation for IT managers with significant IT budget to
> spend it to high-priced products in order to enter club of "big guys"
> with (probably) better career opportunities , instead of following
> common sense and choose most efficient solution.

If IT managers have been money, they will spend it, usually to bring
them out in respect to liability. They simply want to call Microsoft,
Oracle if something bad happens with their DBMS. ;-)

> In fact, migration to MSSQL (or Oracle, etc) is 100%
> mandatory/recommended only if database size is bigger than 1Tb or number
> users are more than 500. This situation can be changed with continued
> price decreasing for RAM, SSDs and other hardware.
> Right now I have draft case study from Australian company with 700Gb
> database (which is growing by 5-6 Gb per month) with hundred of users.
> Hopefully it will help (with others case studies
> http://www.firebirdsql.org/en/case-studies/) IT managers and developers
> to make right decisions.

Is the case study of the Australian company already available?


--
With regards,
Thomas Steinmaurer (^TS^)
Firebird Technology Evangelist

http://www.upscene.com/
http://www.firebirdsql.org/en/firebird-foundation/