Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Channels ▼


Digital Imaging, Databases, and Eye Care

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.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.