meta data for this page
Pros and cons
This section describes reasons to migrate an existing database to Firebird, and reasons not to.
Why migrate to Firebird
This depends mostly on what version you are currently using and what you are using MS SQL for.
For example, if using MS SQL 6.5, it is a simple matter of considering the features and ease of use. MS SQL 6.5 will work with fixed devices rather than dynamically expanding files, which makes it very difficult to balance ease of administration versus available space. There are numerous bugs and annoying behaviours which if you are using MS SQL 7, you know a lot of the little quirks have been removed, but you are still missing some great features, such as updateable views, greater control over identity fields, user-defined functions, and selectable stored procedures. You also don't get cascading referential integrity until the 2000 version. Ditto for using different collation orders in the same database.
For UNIX-like environments, Firebird can have its security integrated with the operating system's. However, this should be discouraged for portability.
MS SQL 2000 improved on MS SQL 7, but is still missing one of the key pieces of Firebird: the multi-generational architecture, which enabled long-running queries to work without getting in the way of traditional short-lived operational transactions. MS SQL will instead try to convince users to buy yet another server (hardware, operating system and database server), set it up as a data warehouse, and use this second server as a source for reports. One can only wonder about the need for a data warehouse in an integrated environment with cross-database query capabilities.
Another reason to migrate is to avoid vendor lock-in. MS SQL will only run on Windows NT/2000 (there are so-called personal editions, but these are limited in available connections and features). This means you are tied to Microsoft for your operating system and your database server. Firebird will run on many platforms, including Microsoft Windows, Linux, Solaris, MacOS X, and others.
Yet another reason to consider is price. Firebird is free; MS SQL will require a considerable amount of money on a per-processor basis. For example, a database accessed through the internet on a dual CPU - Intel Xeon/Opteron machine will cost $54,990 (prices obtained from Microsoft's site on 14 Sep 2010).
Last, but certainly not least, is the fact that Firebird is open source. This not only means that there are hundreds of developers willing to help you use it, improve on it, find bugs, etc., but that you can even modify it and rebuild it yourself to “scratch your itches”. Adding features such as an integrated email system or logging is a matter of understanding the source code and having the available expertise to modify it. While this may not be a trivial task, it is certainly doable, and brings an enormous degree of flexibility.
Why not migrate to Firebird
The first, overriding reason should be because your system is working fine as it is. If this is the case, consider Firebird for future projects, but do not break what is currently working.
There are a number of features MS SQL 7 has that you will not find in Firebird, such as integrated replication support (this is available as an add-on to Firebird), temporary tables, and integration with other database systems through OLE DB. It also has an OLAP Analysis services built into it, and native full-text search (this is available as an add-on to Firebird).
On Microsoft environments, MS SQL 7 and above can have its security integrated with the operating system's. However, this should be discouraged for portability and performance issues.
MS SQL 2000 also has the ability to work with XML directly, and supports partitioned views for better performance on tables which span several servers.
In general, it would seem that MS SQL has better performance on Windows than Firebird on Windows does. It also has better integration with Microsoft Visual Studio.