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)










> We are using Firebird and I've been tasked with determining the costs
> 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.
>
> 



[Non-text portions of this message have been removed]

Reply via email to