Subject | Re: [firebird-support] Sizing conversion project |
---|---|
Author | Alexey Kovyazin |
Post date | 2012-01-21T11:48:43Z |
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? :)
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.
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.
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.
Regards,
Alexey Kovyazin
IBSurgeon (www.ib-aid.com)
Firebird Project (www.firebirdsql.org)
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? :)
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.
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.
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.
Regards,
Alexey Kovyazin
IBSurgeon (www.ib-aid.com)
Firebird Project (www.firebirdsql.org)
> We are using Firebird and I've been tasked with determining the costs[Non-text portions of this message have been removed]
> for migrating to MS SQL Server. The last time I used the latter was ten
> years ago, and in the role of a Java programmer.
> Does anyone have any suggestions for how to come up with rough time and
> cost estimates?
>
> Also, I'd like pointers to FB vs. SQL Server comparisons, so I add those
> to the analysis. Obviously if the benefits don't exceed the costs of
> the migration, it won't make sense.
>
> Last, I'd like to exceed the requirements and throw in DB2 and Oracle.
> If we're forced to migrate, it doesn't make any sense to only consider
> one database.
>
> Thanks, Rick DeBay
>
> Disclaimer: This message (including attachments) is confidential and
> may be privileged. If you have received it by mistake please notify
> the sender by return e-mail and delete this message from your system.
> Any unauthorized use or dissemination of this message in whole or in
> part is strictly prohibited. Please note that e-mails are susceptible
> to change. RxStrategies, Inc. shall not be liable for the improper or
> incomplete transmission of the information contained in this
> communication or for any delay in its receipt or damage to your
> system. RxStrategies, Inc. does not guarantee that the integrity of
> this communication has been maintained nor that this communication is
> free from viruses, interceptions or interference.
>
>