Re: object databases

Responding to Sasa...

I posted this to comp.databases, but then it came to me that you guys might provide some suggestions, sorry if this is an OT:

So after years of using strictly relational databases, I've begun to consider an alternative. Object databases seem compelling, especially since the data in the project I'm mostly involved in is highly hierarchical. So the questions:

Actually, an ODBMS is not inherently well suited to hierarical relations. The OO paradigm is actually designed to eliminate them. OTOH, one can map something like a tree in either one through relationships. IOW, the Data Model looks the same for both:

0..* parent of
[Node] ---------------+
| 0..1 |
| child of | R1
| |
+------------------+

1) When would you recommend ODBMS, and when RDBMS?

If the relationships among tuples of data are complex and more naturally expressed directly between tuples, then and ODBMS is a better choice. For example, most road map applications use a ODBMS because every item usually has a host of fixed relationships to other items of different types AND the number of items involved in a specific relationship is usually a tiny subset of all the items. Perhaps more important, one always navigates the relationships in exactly the same way (i.e., the relationships are defined tailored to the problem in hand). An ODBMS will also usually be more efficient if you have a lot of navigation from the 1-side of 1:* relationships (which is also common in road map applications).

An RDBMS is better suited to situations where relationships between tuples are fairly simple and the individual tuples are related in an arbitrary manner. An RDBMS shines in processing ad hoc queries where one cannot predict exactly what subsets of data will be accessed. For an online airline reservation system one has a relatively few relationships whose navigation can be optimized by a few indices in order to access arbitrary tuples in simple joins.

Bottom line: an ODBMS works well when the data needs to be modeled for a very specific purpose or one routinely needs very complex join. Meanwhile an RDBMS works well when the data is accessed in an ad hoc manner and joins are relatively simple.

2) Which ODBMS would you recommend?

Sorry, I've only used one (ObjectStore) and that was many moons ago so I don't have comparative data.

3) The application I work on is single user desktop application. The data resides on the user's computer. Is there any ODBMS suitable for this (something like equivalent to MSDE, Access, etc.). Is there any "lightweight" object database suitable for this, or would you recommend something else instead?

If it is for a single application, that suggests that the data model can be tailored to a particular problem solution, which /might/ make an ODBMS a better choice. But it would still depend on how complex the relationships were and the nature of the joins.

You can get ODBMSes for desktops, particularly the memory-mapped ones like ObjectStore that directly support persistence in OO applications fairly transparently. But they tend to be pricey. (An ODB engine, particularly a memory-mapped one, is inherently more complex than an RDB engine.)

Note that a memory-mapped ODBMS has a downside for its convenience in managing persistence in an OO application. The application is littered everywhere with infrastructure statements that are specific to the ODBMS and that tends to marry one to a particular vendor. That is in contrast to an RDBMS where one can encapsulate the access mechanisms like SQL in a single client subsystem.

*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@xxxxxxxxxxxxxxxxx for your copy.
Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH



.

Relevant Pages

  • Re: How proprietary is the "COBOL file system"
    ... I think the jury is still out on ODBMS... ... There is a conflict between hiding data in objects versus exposing it in an RDBMS. ... Foreign keys add a third dimension, yet no one objects to that. ... Multiple schemas, instances, links to other databases ...
    (comp.lang.cobol)
  • Re: object databases
    ... So after years of using strictly relational databases, ... Object databases seem compelling, especially ... When would you recommend ODBMS, ...
    (comp.object)
  • Re: object databases
    ... So after years of using strictly relational databases, ... When would you recommend ODBMS, ... Are you aware that object databases failed miserably to gain any ...
    (comp.object)
  • Re: object databases
    ... So after years of using strictly relational databases, ... Object databases seem compelling, especially ... When would you recommend ODBMS, ...
    (comp.object)
  • Re: object databases
    ... Probably the most typical method is to use O/R mapping tools to allow you to ... Object databases seem compelling, especially ... When would you recommend ODBMS, ...
    (comp.object)