someone wrote:
Well, we can't quote the message here due to disclaimer included in it, but you can read the message here
To sum it up, it's about estimating cost and benefits of migration from Firebird to MSSQL. It sparked some interesting replies...
Alexey Kovyazin replied:
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) IT managers and developers to make right decisions.
Alexey Kovyazin replied to comment from Thomas Steinmaurer:
Thomas:
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. ;-)
I used to sit near technical support team in Microsoft, including MSSQL, Exchange, etc.
Without support contract they will do nothing (except point you to MSDN search).
With support contract they can give you advice and answer some questions, but nobody will repair database or deep dive into issues, like connecting to your server by remote desktop, reviewing configuration and environment. There are few exceptions for Gold (Advanced) level partners, but "normal" customers are not treated like kings.
Approach for disaster recovery, as an example - make backups (if you don't, you are not serious enterprise, and we don't work with not serious companies - 100% true!).
Approach for high performance - suggest to hire/train stuff with MS certificates.