- Has management already decided on the computer hardware to be used for this project? If so, the database chosen must run on that hardware.
- Is the database likely to move to different computer hardware in the future? If so, it is better to choose a database platform that runs on multiple operating systems rather than one like SQL Server, which limits you to Windows server operating systems on Intel platforms.
- Can the database software in question handle the workload (number of users, number of database updates, sizes of reports) that your database will have to support? As unforeseen demands seem to creep in later, take the estimate, double it, and add another 20 percent for a really accurate forecast.
- Does your management or user community have a preference of database platform? The degree to which you give your "customers" what they're asking for often determines the degree to which they are satisfied with the end product. So, unless they're asking for something very unrealistic (like Oracle on a Unix machine in an organization that is Microsoft Windows NT-based), it generally pays to follow their recommendations.
- How much data will be stored? If the data ranges into the tens of gigabytes, you will need a true database server like Oracle rather than a desktop database like Access.
- In which databases do the database administration and application development staff have expertise? You will usually be better off choosing a database in which personnel are already skilled.
- Does the database system software you're considering have a large installed base, or does it have a smaller user base? In some cases, large organizations are hesitant to go with products developed by smaller database software companies, figuring that larger database software companies, like Oracle, are more likely to be around in 10 or 15 years, than is a smaller company.
- Can programmers design software to access data in this database using database-server-independent development tools, so that it is easier to move the application to a different vendor's database server if that is ever required? Along with installed base and hardware variety, this is a "safety" measure to consider when choosing a database, so that the company is not left high and dry if the database vendor goes out of business or a database capability is not supported in the current database but is supported in a similar one.
- If you are purchasing an application system (such as a human resources management package) from another company, does that company have a preference for the underlying database? An application may be able to run using a variety of databases, but its developers may know that it works best on one in particular.
Another criteria to keep in mind is performance. An interesting Web page for database professionals to visit from time to time is www.tpc.org, the home page of the Transaction Processing Performance Council (TPC).This site contains benchmark results for an assortment of database activities, listing the best-performing combinations of computer hardware, operating system software, and database system software. (A benchmark is a measurement of how fast a particular combination of hardware and software performs a very specific set of computerized tasks. Benchmarks are useful as guidelines in determining relative performance levels of several different alternative hardware/software combinations.) On the TPC site you will find the numbers to back up comments made in this article about the scalability of database products such as DB2 to very large amounts of data-one of the test database sizes is 300GB! You can check this site periodically to see how your preferred database software is doing compared to other popular database software without the "marketing spin" that tends to accompany vendors' press releases about their product's benchmark performance.
Ultimately, the decision of which system to use conies down to what works best given a set of organizational preferences and technical requirements. The more you know about the alternatives, the better choice you will be able to make. As a database designer or administrator, you are responsible for matching the project's needs with the available database platforms in a manner that satisfies your management.
Let's look at an example of a situation in which you might use more than one database product in your organization. Suppose Oracle is your organization's standard database. It might not be the best database platform for every database application your organization needs, but your management has decreed, "We are an Oracle shop," and for most purposes, it works well enough. So far, every major database created in your department has been created in Oracle.Your company has a sales force of 100 sales reps, each of whom carries a Windows 98-based laptop while on the road and who frequently need to call in to your organization to get price quotes and inventory information.To eliminate the need for sales reps to manually call in to the main office and ask for this data, you can extract the relevant pieces of data from the large Oracle system into a smaller database, which can be loaded onto each salesman's laptop.
Because Oracle is a server database, and one that requires a bit of maintenance, it is not a good choice for use on a small army of laptops used by nontechnical staff. Instead, you might choose to create a Microsoft Access database for each salesman that contains only information relevant to a particular salesman's territory. In these types of situations, creative thinking and knowledge of the capabilities of different types of databases allow database professionals to best serve the organization for which they work. Sometimes that means explaining to management that an "outside the box" solution, like an Access database in a primarily Oracle environment, is best. Learning at least some of the basics of the most popular platforms will be useful to you and the clients you may be serving.
