Object Oriented Database Learning Center

Objectivity Home - Government - Objectivity/DB - Webinars - Download Software

Download a PDF version of this Article

Table of contents:

Object Oriented Database vs Relational Database

• Introduction
• The Wall: Where an RDBMS breaks down
• Programming Time and Cost
• Integrity Loss
• Performance
• Information Model Issues
• Architecture Issues
• Benchmark
• Benchmark Parameters
• Benchmark Execution
• Parts Creation
• Updates
• Deletes
• Selects
• Summary
• Examples
• Cimskil (Manufacturing)
• Exxon (Configuration and FEA)
• CERN (Data Gathering and Analysis)
• Decision•ism (Decision Supportware)
• QUALCOMM (Telecommunications)
• COM21 (Cable Modem)
• Nortel, Sprint (Cell Phone Base Station Management)
• Nousoft (Library Document Management, Web)
• Iridium (Telecommunications)
• BBN (Military Logistics and Control)
• Intraspect (Knowledge Management)
• Fisher-Rosemount (Manufacturing, Process Control)
• A Brief Overview of Our Development
• ODB Selection
• Introduction
• Performance
• Scalability
• Productivity
• Fault Tolerance
• Additional Features and Benefits
• Summary
• Kintetsu (Transportation, Logistics)
• Siemens (Process Control)
• SEH (Semiconductor Manufacturing)
• NEC (Semiconductor Manufacturing)
• American Meter (Process Control)
• Sloan Digital Sky Survey (Geographic Information System)
• LMS (Healthcare, Fetal Monitoring)
• Synthesis (Healthcare, Record Management)
• Daikin (Multi-Media CD-I Authoring)
• How to Avoid the Wall

Object Oriented Database vs Relational Database

Programming Time and Cost

Depending on the application, this translation code can easily grow to more than half the application. In one case (see American Meter Systems, below), a user moved from an RDBMS to an ODBMS (Objectivity/DB) and literally discarded one third of his application (and also achieved far better performance, taking the product from near failure to commercial success). Instead of programming, and maintaining, this translation layer, your programmers could instead be programming your applications, and saving a third to a half of their time and cost.

This effect is amplified during maintenance. Studies show that up to 80% of the lifetime cost of applications is in maintenance, during which time features are added, bugs are fixed, capabilities changed, all of which require changes to the data model underneath. When the application changes its data model, this tends to amplify, through the mapping layer, into many changes, both in that mapping layer and in the flat tabular data underneath. In the words of one user (see Iridium, below), this makes the mapping "brittle," and dramatically increases cost and potential errors.