Identifying the Database Backbone: Solving the "Impedance Mismatch"
Two important criteria for selecting a database were the ability to store any object and to support distributed data sets. In essence, we asked, "Can the system handle our data? And is it reliable?"
The other key issue was avoiding wasting time and effort on the well-documented "impedance mismatch" that occurs when trying to use a relational database management system (RDMS) from an object-oriented program. If we chose that route, we would have faced months of painstaking data access logic coding -- as records and columns would need to be manually converted to objects and qualities. This typically results in poorly performing code that is difficult to maintain.
Our team evaluated a number of solutions, and we quickly concluded that we needed a single, reliable engine rather than a variety of technologies patched together. We ruled out the idea of using a traditional RDBMS because of the impedance mismatch issue and the fact that it couldn't accommodate our distributed environment.
We settled on db4o, an object-oriented database library from db4objects that's designed to be embedded in clients or other software components, completely invisible to the end user. db4o needs no separate installation, configuration, or setup on target machines. Rather, it runs in the same process as your application, so you have full control over memory management and can perform speed profiling and debugging over the entire system.
Using an embedded server is much more efficient from an implementation standpoint. First, it only requires a fraction of the resources that other systems would hog, since there's no need for its own separate processor or memory. (db4o has a small footprint of about 400KB). Secondly, the schema upgrades automatically when you implement new versions of your software, with no need for any form of data model update management. So an entire work package and source of errors are eliminated.
This is in sharp contrast to the labor-intensive process of distributing a MySQL or SQL Express-based system, for example.
A Dynamic System that Keeps Evolving
db4o is now used to store all of the data collected in RetCam II, with the ability to accommodate up to 100,000 objects stored in one typical system database. Note that Clarity Medical Systems doesn't maintain a centralized database. Rather, each of our RetCam II units built is completely autonomous, and db4o resides within the application as a resource.
We did look at a number of alternative platforms, but db4o had the requisite key strengths:
- The ability to store complex object structures, as they occur in medical, biotech and healthcare.
- Support for ACID transactions (full reliability).
- Efficient use of reflection (the capability to self-adjust to changing conditions).
- Speedy performance.
- Powerful OO query language syntax, which enables object-oriented retrieval of objects from the database without complicated syntax.
As noted, it also helped us bypass the typical "distribution nightmare" of traditional OO databases -- the need to migrate existing (patient) data between object versions. This occurs because the code object model is usually in the data-persistence format, so any changes or re-factorings to the code between major releases also affect the database. But db4o provides automatic adjustment for updates and modifications of the object model, making it perfect for re-factoring evolving object models and updating the system with "zero-administration."
db4o is also coupled with programming languages that support reflection (Java and .NET), giving it the ability to analyze executing code during runtime. Therefore, the database has the power to support a fully dynamic software system, like a biological organism that keeps evolving, without the limitations of having to predefine data structures as necessary in RDMS.
