Maintainability
Unless you have worked in an environment where Software Engineering accounts for a large portion of the Services or Sales, maintainability, in my opinion, does not get enough attention. It may not be at the top of the list but its priority can most times be placed above cost. In a healthcare environment this problem is exacerbated seemingly because of lack of planning. By this I mean in my experience no one is concerned about an application unless it does not work, then, and only at that time, does the application receive any attention. Even when the planning and design phase of an implementation was long, there have only been a few projects that I have been introduced to after the implementation that had contained detailed maintenance schedules or planning.
Maintainability is the ability of the database to “take care of itself”. A good maintenance plan can keep a large database fast and reliable when others become more sluggish and harder to keep running as they get larger and older. A database’s ability to reindex, or instance, if this is a manual process or must be done while the database is down, can cause problems for most applications. How are regular backups handled? Will there be an archive schedule, so that we will always be able to retrieve older data? These are important questions that must be answered if disaster, or catastrophic, recovery is needed.
Flat files are proprietary, they will only provide these services if it is part of the application itself. The user is repsonsible for such services if they are not provided. ISAM databases may have some of these services, but they are usually a manual process that must be executed by someone regularly. Though in some situations these processes can be automated if the user has enough technical experience with the application or database.
Most client/server databases have the functionality to handle the basic maintenance procedures, and some can let the user setup very detailed and powerfull data import/export/modification procedures. The only caveot being thta with most of the complex databases require their own administrator. Someone whose focus is toward the database and the database alone. More staff requires a higher cost but this one person can maintain a database, or databases, that serve many applications so the cost can be spread out over many projects.
Just remember if the application is not going to be used for very long, or if it is going to be replaced in the near future, maintainability is not a great conscern. But if the application is of a higher importance, or critical, will not be replaced anytime soon, and will be used for the forseeable future a maintainable database is recommended and maintenance should be part of the design and planning for the solution.
