RE: [firebird-support] Sizing conversion project
For my WAG I used COCOMO 81 with KLOC from the stored procedures and triggers, as feedback here implies that it will all have to be rewritten. I'm assuming that tables, views, and constraints can be converted with a migration tool. -Original Message- From: firebird-support@yahoogroups.com [mailto:firebird-support@yahoogroups.com] On Behalf Of Rick Debay Sent: Monday, January 23, 2012 11:53 AM To: firebird-support@yahoogroups.com Subject: RE: [firebird-support] Sizing conversion project You mean beside licensing cost? I was hoping to use a SWAG such as cost per LOC to estimate the database conversion cost; most of our code is in triggers, stored procedures, etc. Do you use some Firebird specific features like Events? We have the hooks in place (Firebird generates events) but we don't have any apps that listen to the events right now. It's on the to-do list. What programming language/libraries are used? If code is not properly decoupled from database access it can mean rewrite of large portions of the codebase. We use Java. And I do my best to make sure the code is properly decoupled whenever I do a code review :) why are you even considering I wasn't told. -Original Message- From: firebird-support@yahoogroups.com [mailto:firebird-support@yahoogroups.com] On Behalf Of Milan Babuskov Sent: Saturday, January 21, 2012 9:46 AM To: firebird-support@yahoogroups.com Subject: Re: [firebird-support] Sizing conversion project Rick Debay wrote: 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? You mean beside licensing cost? That depends largely on your applications and databases, so we would need more details: Do you use some Firebird specific features like Events? What programming language/libraries are used? It's easier to make a switch if you use Java application than if you use IBPP C++ library for example. Java might require a simple reconfiguration, while C++ would require rewrite of database access layer. If code is not properly decoupled from database access it can mean rewrite of large portions of the codebase. 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. As someone who migrated from MSSQL to FB, I'd like you to first tell us why are you even considering going from rock-solid robust open source database to a closed one which has similar performance and feature set? -- Milan Babuskov == The easiest way to import XML, CSV and textual files into Firebird: http://www.guacosoft.com/xmlwizard == ++ Visit http://www.firebirdsql.org and click the Resources item on the main (top) menu. Try Knowledgebase and FAQ links ! Also search the knowledgebases at http://www.ibphoenix.com ++ Yahoo! Groups Links 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. ++ Visit http://www.firebirdsql.org and click the Resources item on the main (top) menu. Try Knowledgebase and FAQ links ! Also search the knowledgebases at http://www.ibphoenix.com ++ Yahoo! Groups Links
RE: [firebird-support] Sizing conversion project
You mean beside licensing cost? I was hoping to use a SWAG such as cost per LOC to estimate the database conversion cost; most of our code is in triggers, stored procedures, etc. Do you use some Firebird specific features like Events? We have the hooks in place (Firebird generates events) but we don't have any apps that listen to the events right now. It's on the to-do list. What programming language/libraries are used? If code is not properly decoupled from database access it can mean rewrite of large portions of the codebase. We use Java. And I do my best to make sure the code is properly decoupled whenever I do a code review :) why are you even considering I wasn't told. -Original Message- From: firebird-support@yahoogroups.com [mailto:firebird-support@yahoogroups.com] On Behalf Of Milan Babuskov Sent: Saturday, January 21, 2012 9:46 AM To: firebird-support@yahoogroups.com Subject: Re: [firebird-support] Sizing conversion project Rick Debay wrote: 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? You mean beside licensing cost? That depends largely on your applications and databases, so we would need more details: Do you use some Firebird specific features like Events? What programming language/libraries are used? It's easier to make a switch if you use Java application than if you use IBPP C++ library for example. Java might require a simple reconfiguration, while C++ would require rewrite of database access layer. If code is not properly decoupled from database access it can mean rewrite of large portions of the codebase. 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. As someone who migrated from MSSQL to FB, I'd like you to first tell us why are you even considering going from rock-solid robust open source database to a closed one which has similar performance and feature set? -- Milan Babuskov == The easiest way to import XML, CSV and textual files into Firebird: http://www.guacosoft.com/xmlwizard == ++ Visit http://www.firebirdsql.org and click the Resources item on the main (top) menu. Try Knowledgebase and FAQ links ! Also search the knowledgebases at http://www.ibphoenix.com ++ Yahoo! Groups Links 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.
Re: [firebird-support] Sizing conversion project
Em 23/1/2012 14:53, Rick Debay escreveu: You mean beside licensing cost? I was hoping to use a SWAG such as cost per LOC to estimate the database conversion cost; most of our code is in triggers, stored procedures, etc. So I think you will have a *lot* of work to be done... It's a long time ago since I used MSSQL, but I doubt it became more compatible to PSQL I think that the worst scenario ever for migrating from a RDBMS to another is conversion of SP and triggers, if all your business logic is coded inside PSQL code, you will need to rewrite it from sctrach. good luck !
Re: [firebird-support] Sizing conversion project
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]
Re: [firebird-support] Sizing conversion project
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
Re: [firebird-support] Sizing conversion project
Hello Thomas, Thanks for comments! 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. 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? No published yet. I'm waiting for approval of almost final version. Regards, Alexey Kovyazin
Re: [firebird-support] Sizing conversion project
Rick Debay wrote: 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? You mean beside licensing cost? That depends largely on your applications and databases, so we would need more details: Do you use some Firebird specific features like Events? What programming language/libraries are used? It's easier to make a switch if you use Java application than if you use IBPP C++ library for example. Java might require a simple reconfiguration, while C++ would require rewrite of database access layer. If code is not properly decoupled from database access it can mean rewrite of large portions of the codebase. 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. As someone who migrated from MSSQL to FB, I'd like you to first tell us why are you even considering going from rock-solid robust open source database to a closed one which has similar performance and feature set? -- Milan Babuskov == The easiest way to import XML, CSV and textual files into Firebird: http://www.guacosoft.com/xmlwizard ==
Re: [firebird-support] Sizing conversion project
On 21-1-2012 15:46, Milan Babuskov wrote: What programming language/libraries are used? It's easier to make a switch if you use Java application than if you use IBPP C++ library for example. Java might require a simple reconfiguration, while C++ would require rewrite of database access layer. If code is not properly decoupled from database access it can mean rewrite of large portions of the codebase. Although switching between JDBC drivers and databases is relatively easy, if you don't use an ORM or JPA-implementation like Hibernate or EclipseLink, you will probably need to rewrite (some of) your queries. And even if you use a JPA-implementation (or another ORM) you will need to make some changes to account for differences in feature support. Mark -- Mark Rotteveel
RE: [firebird-support] Sizing conversion project - Email found in subject
-Original Message- From: firebird-support@yahoogroups.com [mailto:firebird- supp...@yahoogroups.com] On Behalf Of Doug Chamberlin Sent: Friday, January 20, 2012 6:26 PM To: firebird-support@yahoogroups.com Subject: Re: [firebird-support] Sizing conversion project - Email found in subject On 1/20/12 5:23 PM, Rick Debay wrote: Obviously if the benefits don't exceed the costs of the migration, it won't make sense. Seems to me there is nothing obvious about this question at all. I can see you being able to estimate the costs - increased licensing, required hardware, necessary labor, anticipated downtime, etc. But what benefits can there be that are able to be compared directly to those costs? Then there is the cost of porting the FB functionality: - the loss of row level triggers (SQL Server only support statement level triggers). - the loss of SELECT * FROM SP - the increased contention of readers vs. writers. Sean P.S.You are really asking in the wrong forum, you should really find someone who has done the move. No developer willingly moves from an existing/known solution -- look at all the COBOL application which are still running today.
