More on Choosing a DBMS

For those requesting more details on DBMS selection criteria.

A couple of days ago I posted a blog entry on Choosing a DBMS. In it I provide some high-level guidance on selecting database management software. However, since I do not want it to sound as if the selection of a DBMS is a no-brainer, I am following that post up with some additional guidelines.

You will need a strategy and a plan for selecting the appropriate DBMS for your specific situation. There are criteria that should be applied during the selection process. When choosing a DBMS, be sure to consider each of the following factors:

Operating system support – does the DBMS support the operating systems in use at your organization? The versions of the operating systems that you are currently using and plan on using?

Type of organization – your corporate philosophy should be taken into consideration when choosing a DBMS. Some organizations are very conservative and like to keep a tight reign on their environments; these organizations tend to gravitate towards traditional mainframe environments. Government operations, financial institutions, and insurance and health companies usually are more conservative than other types of companies. Other organizations tend to be more liberal and often are willing to consider alternative architectures. It is not uncommon for manufacturing companies, dot-coms, and universities to be less conservative. Finally, some companies just do not trust Windows as a mission critical environment, and prefer to use UNIX – this rules out some database vendors (Microsoft SQL Server, in particular).

Benchmarks – what measured performance benchmarks are available from the DBMS vendor and other users of the DBMS. The Transaction Processing Performance Council (TPC) publishes official database performance benchmarks that can be used as a guideline for the basic overall performance of many different types of database processing. Refer to the SideBar on the Transaction Processing Performance Council for more details. In general, performance benchmarks can be useful as a broad indicator of database performance. But do not use benchmarks as the only determinant when selecting a DBMS. Many of the TPC benchmarks are run against database implementations that are not representative of most production database systems, and therefore are not indicative of the actual performance that can be achieved with a particular DBMS. Also, there is always a new benchmark being published to show new and improved performance measurements for each of the major DBMS products, rendering the benchmark “winners” obsolete very quickly.

Scalability – does the DBMS support the number of users and database sizes you intend to implement? How are large databases built, supported, maintained – easily or with a lot of pain? Are there independent users who can confirm the DBMS vendor’s scalability claims?

Availability of supporting software tools – are the supporting tools you require available for the DBMS? The tools that may be required include query and analysis tools, data warehousing support tools, database administration tools, backup and recovery tools, performance monitoring tools, capacity planning tools, database utilities, and support for various programming languages.

Technicians – is there a sufficient supply of skilled database professionals for the DBMS? Consider your needs in terms of DBAs, technical support personnel (system programmers and administrators, operations analysts, etc.) and application programmers.

Cost of Ownership – what is the TCO (Total Cost of Ownership) of the DBMS? The DBMS vendors charge wildly varying prices for their technology. TCO should be calculated as a combination of the license cost of the DBMS, the license cost of any required supporting software, the cost of database professionals to program, support and administer the DBMS, and the cost of the computing resources required to operate the DBMS.

Release schedule – how often does the DBMS vendor release a new version? Some vendors have rapid relase cycles with new releases coming out every year to 18 months. This can be good or bad depending on your approach. If you always want to support leading edge features, a rapid release cycle is good. However, if your shop is more conservative, a DBMS that changes so quickly can be difficult to support. A rapid release cycle will cause conservative organizations either to upgrade more frequently than they would like or to utilize outdated DBMS software that is unlikely to have the same level of support as the latest more recent release. The basic issue here can be summed up as dealing with complexity.

Patch schedule - In this day and age of security and data breaches DBAs need to be cognizant of how often their database software needs to be patched. How responsive is the vendor to releasing security patches when holes are identified? Is there a regular patch cycle? Will the vendor release patches off-cycle for particularly thorny problems?

Reference customers – will the DBMS vendor supply current users of their product who can be reached for reference? And can you find other users on your own (that were not specially selected by the vendor and might give different and perhaps more honest answers). Speak with those currently using the DBMS to elicit issues and concerns that are impossible to capture on paper or in a checklist of features and functionality. How is support? Does the vendor respond well to problems? Do things generally work as advertised? Are there a lot of bug fixes that must be applied conituously? What is quality like for new releases? These are the types of questions that can only be answered by the folks in the trenches.

Finally, give some thought to any of your specific "burning" issues and whether one particular DBMS is better-suited to achieving your goals. For example, if .NET development is high on your priority list make sure the DBMS you select supports that technology well.

Hope that list helps you out somewhat. And good luck selecting your DBMS software.

Friday, March 17, 2006 | Permalink | Comments (0)

trackback URL: http://www.dbazine.com/blogs/blog-cm/craigmullins/blogentry.2006-03-16.1268366073/sbtrackback

DBAzine.com

Sections

Personal tools

Menu

Who Are You?

More on Choosing a DBMS