NEDARC POSITION PAPER

Transcription

1 Which Database Will Serve Your Needs? National EMSC Data Analysis Resource Center Central to any EMS, public health, or large healthcare organization is the collection, storage, retrieval, and analysis of information. It is important to accomplish these tasks in an efficient, dependable and hopefully easy-to-use manner, and with little or no time spent chasing bugs or waiting for a search to complete. Unfortunately, these ideal characteristics of a computer system seldom come in the same package! There is such a wide range of databases on the market today, how do you decide which database is right for your needs? This difficult decision can be assisted by answering a series of questions about you, your organization, the size of the database, and how many people will be accessing the database. Once these questions are answered, the long list of database choices can be narrowed. What Are The Choices? Page 1 of 4 There are several different types of databases, but to simplify our discussion, we are going to suggest that relational databases are the primary type of database used in today s organizations. Relational databases may be broken into two categories: 1) databases that run on your desktop computer, and 2) databases that are running on a separate server, usually in a different location from your desktop computer. We will call the first category desktop databases and the second category will be called client server systems. Client server systems are more complicated because there is a program running on your computer ( client ) that connects to the database itself on the server ( server ), and this requires a network. The explosive development and availability of the Internet has provided this network to nearly every organization, and client server database systems are now widely available. Desktop databases are installed on a single computer in a manner similar to other office applications (word processing, spreadsheets, , desktop publishing, etc.). All of these programs run right on your computer. In some organizations, these programs may be stored on a network computer, and perhaps your desktop computer doesn t even have a disk of its own. But even in these cases, the program actually loads on your desktop computer when you use it, and it requires the brains of your computer (the central processing unit, or CPU, such as the Pentium 4 chip) to actually do the work of the program. Desktop databases include Microsoft Access, Paradox, Dbase versions, Filemaker Pro, Foxpro, and many others. These programs almost always include very nice editing systems, report generators, user manuals, and so forth, and modern versions provide very high performance if the database is stored on the same desktop computer. For this situation, when you are a single user of a database, these packages provide excellent value and can handle databases approaching 1 million records or more. With large databases, or with databases designed for many users and millions of records, it becomes desirable to share the database among more users, or to store the database on a larger machine so that your organization can provide

2 automatic backup of the data, etc. When this happens, the data no longer live on your own machine. In this case, desktop database programs such as Access can still be used, and modern versions are smart enough to allow several people to use the same database from their own computers (even if not simultaneously). Each of their computers must be actually running the application (such as Access), and they look for the data itself on a file on the network server. This is NOT the same thing as a client server system. This is simply storing the data on a network drive. When you ask for all the ambulance run records for children under the age of 15 years, your program (on your computer) must open the database, and all the records contained in the database must come to your computer to find out the age of each patient. So, if there are 1 million ambulance records on the network drive then it is necessary for all 1 million records to move over the network to get to your computer. Your computer program (Access) examines each record, and keeps the ones that are patients under 15 years of age. You may surmise that this system will not have good performance when databases are large, because if you have multiple people using the database, millions of records will be going back and forth between the network drive and each person s individual computer. It is easy to see that this system will deliver poor performance, much worse than if the database was used by only one person and always stayed on his or her personal desktop computer. The key is that when multiple people need the data and it is stored somewhere outside your desktop computer, these desktop database packages do not perform well unless the databases are very small in size with few tables. How small? We would suggest that if your database contains more than a hundred thousand records, and is stored on a network drive to allow multiple people to access the data, then desktop database packages will not be adequate for your organization. You need a client server database system. When you use a client server system and ask for all the ambulance records for children under 15 years, your own computer doesn t really do much work. It just sends a message find all the kids under 15 years on the database and send those records back to my machine. This is fundamentally different than the previous situation, when you asked to see millions of records so that your own machine could find all the kids under 15 years on the database When the database program on the server receives this message, it does all the work itself, and sends back the final result. Consider the situation where you are looking for just 1 single record out of millions. If you used a desktop database application, the whole set of millions of records would come across the network to your computer and it would search for the single record. In the client server system, you would send the message requesting the record and the server would find it without moving the records across the network. This is what greatly speeds up the process. Instead of moving millions of records across the network, the server will just send you the 1 single record you requested. Client server databases are also fundamentally different in the way they hold or lock records from the database. Every time records are requested from the

3 database, a system will lock those records so no one else can make changes to the records while they are open. Just like opening a text document locks the file so on one else can modify it. Most desktop database systems will lock the entire table or a large portion of the table, making the system unavailable to other users. A client server system may only lock those records being returned thus freeing the rest of the system to be used by others. Client server systems may also be faster if the server computer is more powerful, but current technology allows people to have extremely powerful computers on their desktop. The key performance problem when you have a super powerful computer on your desktop is really the network, and how many records actually have to move across it to get to your computer. Client server systems are superior when working with large databases with multiple users because of the incredible time-savings of not moving huge numbers of records around the network. Client server systems are typically expensive, usually require a machine to be dedicated to the database program, and the data are usually stored on these machines in server rooms that are not located in your office. However, these capabilities are present in most organizations, and the universal presence of networks makes these systems very feasible in most EMS settings. Example client server database programs include Microsoft SQL Server, Oracle, DB2, Informix, MySQL, and Sybase. Since these systems are complicated and expensive, you will need to find out if your organization already uses one of these products. For example, if your organization already uses Oracle, you may be able to use it for little or no further expense, and you can benefit from the experiences of people who already know how to use Oracle. How Big Is Your Kingdom? The first consideration when choosing a database is size. How many records will it hold, now and in the future? Can it physically hold all the records you need? If your database will be used by many people and will be kept on a network drive, we have already suggested that you should consider it too large for a desktop program if it exceeds a hundred thousand records. If you are the only user and the database and the data will remain on your desktop computer, you may choose a desktop program for quite large databases. However, most EMS databases will have little value unless many people are using the data, and for this reason, you almost certainly will need to consider client server systems. If you have a very small database such as a list of addresses, you may choose to use a much simpler solution such as a spreadsheet. Just remember that you cannot easily share a spreadsheet with multiple users. If you do need a client server database system, remember that you can use it for all your database needs, even the small ones, if you have people who can help you set the system up for this purpose. How Do I Know How Big It Is?

4 Let s consider a case where the database is to start small and grow constantly, but not massively. Any example will do. The data in the database are not important here. What is important is how many people will be populating it, how often, how many records, and how much information is collected per incident. For an example, we will define a Children s Fracture Database. It will hold records describing all fractures occurring in the pediatric population as a result of all terrain vehicle (ATV) crashes. We know that only 8 to 10 people in our organization will have access to the database, each of them will have the database open for only a few moments at any time, the number of records added is minimal (two or three records once or twice a week) and it only collects 20 fields regarding each incident. Some quick and easy math tells us that this database will not grow to thousands of records for several years. Unless we already have a client server database system, a desktop database is an excellent choice. It is cheaper, easier to install, and simpler to learn and operate. So long as the purpose remains predictable and constant, a desktop database will take care of the Children s Fracture Database and its users for many years to come. We ve Hit the Big Time! But now things get complicated. A new ATV company markets a low cost vehicle and ATV use explodes across the region. Providers are aware of the Children s Fracture Database and send many reports of injuries from crashes. Injury prevention publicity efforts are very successful and the organization housing the Children s Fracture Database is receiving more frequent requests for data and reports. More people are hired to enter and analyze these records, and a couple of them spend all their time at remote sites so they will need remote access to the database. The number of records being entered has increased to 25 per day. There have been numerous complaints from employees who try to gain access to the database but cannot until another user exits. The reporting performance of the database (searching, sorting, retrieving) is still pretty good, but when cases are entered into the database, there is a 10 second delay after each field of data is entered. The data entry staff is becoming very irritated, because most human users are only happy when the maximum delay is about 2 seconds. A change is necessary here or the Children s Fracture Database will not be able to continue its growth, and our organization risks unhappy customers (and employees). Enter the client server database. As we have said, the client server database is the more expensive, more robust, and more complex cousin of the desktop database we have been using. What are the main operational differences? The first is that the database should reside on its own server computer, which means a probable cash outlay. If the organization does not have a technically savvy person to learn how to use the database, the second operational difference will be the need to hire a professional to install, configure, and maintain it. Third, most of the client server database systems don t even include any editors for making data entry screens or reports, so the organization will have to buy software and train users to develop entry screens and reports. This change is therefore not a minor transition, and there are growing pains. Certain client server databases have easier and more intuitive management

5 interfaces (the software tools used to update and administer the data) than others. Joining a computer discussion or newsgroup centered on this topic can help organizations obtain opinions from other organizations that have gone through the work of this transition and experienced the triumphs and pitfalls of the process. Even NEDARC has traveled this journey, and many of our staff can provide you with advice and encouragement. How Do We Get From Here To There? We do one quick check to make sure all the pieces are in place. We have purchased the new server and the new database, we have hired the IT professional (or trained an existing employee), and we are ready to migrate our old desktop database up to our new client server database. Migrating a database is often no more complex than importing records from one database to another. Whatever it is called the process is really the same you are taking records from a database, making a copy of them, and bringing them into a new database. Depending on your choice of client server database, there may be existing tools or wizards to accomplish the transfer. If not, you may need to first export all your records into a medium, such as text files, dbf files, spreadsheets, etc., that can be read by the new database. These intermediary files can then be imported and you re on your way. Another term you may frequently encounter is scalability. This refers to the question of whether your database is going to grow so much in size and/or number of users that you need to consider scaling up your database to handle the increased demands. For example, if you expect to add 10 million records a year to your statewide EMS database, will a Pentium 4 server be adequate or will you have to buy a mainframe computer? Will your computer be fast enough to process 10 or 100 or 1000 simultaneous users in reasonable amounts of time? Will one instance of a client server database be sufficient or will you need to configure a second, third, or more all working in tandem? These questions relate to the scale of what your computer hardware and database software can handle, not just the capability of your database program. For most EMS applications, all the client server systems we have mentioned will scale adequately, and this is not an important problem. If you anticipate having hundreds of users and millions of records, however, you should seek advice on this topic before making a final decision on your database purchase. In Summary Organizing your data using a database program is a smart move. Not only will you be able to retrieve and analyze the data you need in short time, others can ask questions that your data can immediately answer. Those who have been in the data for a while probably have a good idea if their desktop system is working well for them or if they need to scale up. Those new to the arena may be a little overwhelmed at first, but we hope this brief discussion will help you approach the problem with useful and pertinent information. Be patient with yourself and spend some time reading and tinkering with the database. In no time you ll wonder how you ve gotten so far without one.