Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Why Aren't You Using An OODMS?

timothy posted more than 13 years ago | from the because-you-have-another-mantra? dept.

213

Dare Obasanjo contributed this piece about a subject that probably only a very few people have ever taken the time to consider, or had to. Below he asks the musical question "Why aren't you using an Object Oriented Database Management System?"Update: 05/04 02:11 PM by H :This is also running on K5 - yes, that's on purpose, and yes, Dare, myself and Rusty all know. *grin*

Why Aren't You Using An Object Oriented Database Management System?

In today's world, Client-Server applications that rely on a database on the server as a data store while servicing requests from multiple clients are quite commonplace. Most of these applications use a Relational Database Management System (RDBMS) as their data store while using an object oriented programming language for development. This causes a certain inefficency as objects must be mapped to tuples in the database and vice versa instead of the data being stored in a way that is consistent with the programming model. The "impedance mismatch" caused by having to map objects to tables and vice versa has long been accepted as a necessary performance penalty. This paper is aimed at seeking out an alternative that avoids this penalty.

What follows is a condensed version of the following paper; An Exploration of Object Oriented Database Management Systems, which I wrote as part of my independent study project under Dr. Sham Navathe.

Introduction

The purpose of this paper is to provide answers to the following questions

  • What is an Object Oriented Database Management System (OODBMS)?
  • Is an OODBMS a viable alternative to an RDBMS?
  • What are the tradeoffs and benefits of using an OODBMS over an RDBMS?
  • What does code that interacts with an OODBMS look like?
Overview of Object Oriented Database Management Systems

An OODBMS is the result of combining object oriented programming principles with database management principles. Object oriented programming concepts such as encapsulation, polymorphism and inheritance are enforced as well as database management concepts such as the ACID properties (Atomicity, Consistency, Isolation and Durability) which lead to system integrity, support for an ad hoc query language and secondary storage management systems which allow for managing very large amounts of data. The Object Oriented Database Manifesto [Atk 89] specifically lists the following features as mandatory for a system to support before it can be called an OODBMS; Complex objects, Object identity, Encapsulation , Types and Classes ,Class or Type Hierarchies, Overriding,overloading and late binding, Computational completeness , Extensibility, Persistence , Secondary storage management, Concurrency, Recovery and an Ad Hoc Query Facility.

>From the aforementioned description, an OODBMS should be able to store objects that are nearly indistinguishable from the kind of objects supported by the target programming language with as little limitation as possible. Persistent objects should belong to a class and can have one or more atomic types or other objects as attributes. The normal rules of inheritance should apply with all their benefits including polymorphism, overridding inherited methods and dynamic binding. Each object has an object identifier (OID) which used as a way of uniquely identifying a particuler object. OIDs are permanent, system generated and not based on any of the member data within the object. OIDs make storing references to other objects in the database simpler but may cause referential intergrity problems if an object is deleted while other objects still have references to its OID. An OODBMS is thus a full scale object oriented development environment as well as a database management system. Features that are common in the RDBMS world such as transactions, the ability to handle large amounts of data, indexes, deadlock detection, backup and restoration features and data recovery mechanisms also exist in the OODBMS world.

A primary feature of an OODBMS is that accessing objects in the database is done in a transparent manner such that interaction with persistent objects is no different from interacting with in-memory objects. This is very different from using an RDBMSs in that there is no need to interact via a query sub-language like SQL nor is there a reason to use a Call Level Interface such as ODBC, ADO or JDBC. Database operations typically involve obtaining a database root from the the OODBMS which is usually a data structure like a graph, vector, hash table, or set and traversing it to obtain objects to create, update or delete from the database. When a client requests an object from the database, the object is transferred from the database into the application's cache where it can be used either as a transient value that is disconnected from its representation in the database (updates to the cached object do not affect the object in the database) or it can be used as a mirror of the version in the database in that updates to the object are reflected in the database and changes to object in the database require that the object is refetched from the OODBMS.

Comparisons of OODBMSs to RDBMSs

There are concepts in the relational database model that are similar to those in the object database model. A relation or table in a relational database can be considered to be analogous to a class in an object database. A tuple is similar to an instance of a class but is different in that it has attributes but no behaviors. A column in a tuple is similar to a class attribute except that a column can hold only primitive data types while a class attribute can hold data of any type. Finally classes have methods which are computationally complete (meaning that general purpose control and computational structures are provided [McF 99]) while relational databases typically do not have computationally complete programming capabilities although some stored procedure languages come close.

Below is a list of advantages and disadvantages of using an OODBMS over an RDBMS with an object oriented programming language.

Advantages
  1. Composite Objects and Relationships: Objects in an OODBMS can store an arbitrary number of atomic types as well as other objects. It is thus possible to have a large class which holds many medium sized classes which themselves hold many smaller classes, ad infinitum. In a relational database this has to be done either by having one huge table with lots of null fields or via a number of smaller, normalized tables which are linked via foreign keys. Having lots of smaller tables is still a problem since a join has to be performed every time one wants to query data based on the "Has-a" relationship between the entities. Also an object is a better model of the real world entity than the relational tuples with regards to complex objects. The fact that an OODBMS is better suited to handling complex,interrelated data than an RDBMS means that an OODBMS can outperform an RDBMS by ten to a thousand times depending on the complexity of the data being handled.

  2. Class Hierarchy: Data in the real world is usually has hierarchical characteristics. The ever popular Employee example used in most RDBMS texts is easier to describe in an OODBMS than in an RDBMS. An Employee can be a Manager or not, this is usually done in an RDBMS by having a type identifier field or creating another table which uses foreign keys to indicate the relationship between Managers and Employees. In an OODBMS, the Employee class is simply a parent class of the Manager class.

  3. Circumventing the Need for a Query Language: A query language is not necessary for accessing data from an OODBMS unlike an RDBMS since interaction with the database is done by transparently accessing objects. It is still possible to use queries in an OODBMS however.

  4. No Impedence Mismatch: In a typical application that uses an object oriented programming language and an RDBMS, a signifcant amount of time is usually spent mapping tables to objects and back. There are also various problems that can occur when the atomic types in the database do not map cleanly to the atomic types in the programming language and vice versa. This "impedance mismatch" is completely avoided when using an OODBMS.

  5. No Primary Keys: The user of an RDBMS has to worry about uniquely identifying tuples by their values and making sure that no two tuples have the same primary key values to avoid error conditions. In an OODBMS, the unique identification of objects is done behind the scenes via OIDs and is completely invisible to the user. Thus there is no limitation on the values that can be stored in an object.

  6. One Data Model: A data model typically should model entities and their relationships, constraints and operations that change the states of the data in the system. With an RDBMS it is not possible to model the dynamic operations or rules that change the state of the data in the system because this is beyond the scope of the database. Thus applications that use RDBMS systems usually have an Entity Relationship diagram to model the static parts of the system and a seperate model for the operations and behaviors of entities in the application. With an OODBMS there is no disconnect between the database model and the application model because the entities are just other objects in the system. An entire application can thus be comprehensively modelled in one UML diagram.

Disadvantages
  1. Schema Changes: In an RDBMS modifying the database schema either by creating, updating or deleting tables is typically independent of the actual application. In an OODBMS based application modifying the schema by creating, updating or modifying a persistent class typically means that changes have to be made to the other classes in the application that interact with instances of that class. This typically means that all schema changes in an OODBMS will involve a system wide recompile. Also updating all the instance objects within the database can take an extended period of time depending on the size of the database.

Who is currently using an OODBMS to handle mission critical data

The following information was gleaned from the ODBMS Facts website.

  • The Chicago Stock Exchange manages stock trades via a Versant ODBMS.

  • Radio Computing Services is the world's largest radio software company. Its product, Selector, automates the needs of the entire radio station -- from the music library, to the newsroom, to the sales department. RCS uses the POET ODBMS because it enabled RCS to integrate and organize various elements, regardless of data types, in a single program environment.

  • The Objectivity/DB ODBMS is used as a data repository for system component naming, satellite mission planning data, and orbital management data deployed by Motorola in The Iridium System.

  • The ObjectStore ODBMS is used in SouthWest Airline's Home Gate to provide self-service to travelers through the Internet.

  • Ajou University Medical Center in South Korea uses InterSystems' Cachè ODBMS to support all hospital functions including mission-critical departments such as pathology, laboratory, blood bank, pharmacy, and X-ray.

  • The Large Hadron Collider at CERN in Switzerland uses an Objectivity DB. The database is currently being tested in the hundreds of terabytes at data rates up to 35 MB/second.

  • As of November, 2000, the Stanford Linear Accelerator Center (SLAC) stored 169 terabytes of production data using Objectivity/DB. The production data is distributed across several hundred processing nodes and over 30 on-line servers.
Interacting With An OODBMS

Below are Java code samples for accessing a relational database and accessing an object database. Compare the size of the code in both examples. The examples are for an instant messaging application.

  1. Validating a user.

    Java code accessing an ObjectStore(TM) database

    import COM.odi.*;
    import COM.odi.util.query.*;
    import COM.odi.util.*;
    import java.util.*;

    try {

    //start database session
    Session session = Session.create(null, null);
    session.join();

    //open database and start transaction
    Database db = Database.open("IMdatabase", ObjectStore.UPDATE);
    Transaction tr = Transaction.begin(ObjectStore.READONLY);

    //get hashtable of user objects from DB
    OSHashMap users = (OSHashMap) db.getRoot("IMusers");

    //get password and username from user
    String username = getUserNameFromUser();
    String passwd = getPasswordFromUser();


    //get user object from database and see if it exists and whether password is correct
    UserObject user = (UserObject) users.get(username);

    if(user == null)
    System.out.println("Non-existent user");
    else
    if(user.getPassword().equals(passwd))
    System.out.println("Successful login");
    else
    System.out.println("Invalid Password");

    //end transaction, close database and retain terminate session
    tr.commit();
    db.close();
    session.termnate();
    }
    //exception handling would go here ...


    Java JDBC code accessing an IBM's DB2 Database(TM)

    import java.sql.*;
    import sun.jdbc.odbc.JdbcOdbcDriver;
    import java.util.*;


    try {

    //Launch instance of database driver.
    Class.forName("COM.ibm.db2.jdbc.app.DB2Driver").newInstance();

    //create database connection
    Connection conn = DriverManager.getConnection("jdbc:db2:IMdatabase");

    //get password and username from user
    String username = getUserNameFromUser();
    String passwd = getPasswordFromUser();

    //perform SQL query
    Statement sqlQry = conn.createStatement();
    ResultSet rset = sqlQry.executeQuery("SELECT password from user_table WHERE username='" + username +"'");


    if(rset.next()){
    if(rset.getString(1).equals(passwd))
    System.out.println("Successful login");
    else
    System.out.println("Invalid Password");
    }else{
    System.out.println("Non-existent user");
    }

    //close database connection
    sqlQry.close();
    conn.close();

    }
    //exception handling would go here ...

    There isn't much difference in the above examples although it does seem a lot clearer to perform operations on a UserObject instead of a ResultSet when validating the user.

  2. Getting the user's contact list.

    Java code accessing an ObjectStore(TM) database

    import COM.odi.*;
    import COM.odi.util.query.*;
    import COM.odi.util.*;
    import java.util.*;


    try {

    /* start session and open DB, same as in section 1a */

    //get hashmap of users from the DB
    OSHashMap users = (OSHashMap) db.getRoot("IMusers");

    //get user object from database
    UserObject c4l = (UserObject) users.get("Carnage4Life");
    UserObject[] contactList = c4l.getContactList();

    System.out.println("This are the people on Carnage4Life's contact list");

    for(int i=0; i <contactList.length; i++)
    System.out.println(contactList[i].toString()); //toString() prints fullname, username, online status and webpage URL

    /* close session and close DB, same as in section 1a */
    }//exception handling code


    Java JDBC code accessing an IBM's DB2 Database(TM)

    import java.sql.*;
    import sun.jdbc.odbc.JdbcOdbcDriver;
    import java.util.*;


    try {

    /* open DB connection, same as in section 1b */
    //perform SQL query
    Statement sqlQry = conn.createStatement();
    ResultSet rset = sqlQry.executeQuery("SELECT fname, lname, user_name, online_status, webpage FROM contact_list, user_table" + "WHERE contact_list.owner_name='Carnage4Life' and contact_list.buddy_name=user_table.user_name");

    System.out.println("This are the people on Carnage4Life's contact list");


    while(rset.next())
    System.out.println("Full Name:" + rset.getString(1) + " " + rset.getString(2) + " User Name:" + rset.getString(3) + " OnlineStatus:" + rset.getString(4) + " HomePage URL:" + rset.getString(5));

    /* close DB connection, same as in section 1b*/
    }//exception handling code


    The benefits of using an OODBMS over an RDBMS in Java slowly becomes obvious. Consider also that if the data from the select needs to be returned to another method then all the data from the result set has to be mapped to another object (UserObject).

  3. Get all the users that are online.

    Java code accessing an ObjectStore(TM) database

    import COM.odi.*;
    import COM.odi.util.query.*;
    import COM.odi.util.*;
    import java.util.*;

    try{
    /* same as above */

    //use a OODBMS query to locate all the users whose status is 'online'
    Query q = new Query (UserObject.class, "onlineStatus.equals(\"online\"");
    Collection users = db.getRoot("IMusers");
    Set onlineUsers = q.select(users);

    Iterator iter = onlineUsers.iterator();

    // iterate over the results
    while ( iter.hasNext() )
    {
    UserObject user = (UserObject) iter.next();

    // send each person some announcement
    sendAnnouncement(user);

    }

    /* same as above */

    }//exception handling goes here


    Java JDBC code accessing an IBM's DB2 Database(TM)
    import java.sql.*;
    import sun.jdbc.odbc.JdbcOdbcDriver;
    import java.util.*;

    try{
    /* same as above */

    //perform SQL query
    Statement sqlQry = conn.createStatement
    ();
    ResultSet rset = sqlQry.executeQuery
    ("SELECT fname, lname, user_name, online_status,
    webpage FROM user_table WHERE
    online_status='online'");

    while(rset.next()){

    UserObject user = new UserObject
    (rset.getString(1),rset.getString
    (2),rset.getString(3),rset.getString
    (4),rset.getString(5));
    sendAnnouncement(user);

    }


    /* same as above */
    }//exception handling goes here

List of Object Oriented Database Management Systems
Proprietary Conclusion

The gains from using an OODBMS while developing an application using an OO programming language are many. The savings in development time by not having to worry about separate data models as well as the fact that there is less code to write due to the lack of impedance mismatch is very attractive. In my opinion, there is little reason to pick an RDBMS over an OODBMS system for newapplication development unless there are legacy issues that have to be dealt with.

cancel ×

213 comments

Sorry! There are no comments related to the filter you selected.

OOP useful, but not a silver bullet (1)

Anonymous Coward | more than 13 years ago | (#245626)

OOP and other language paradigms are in my mind useful tools, however, all tools have limitations due to the level of specialization that a good tool inherently has in its design. OOP is a very useful tool for a wide class of problems, but not every problem will get a win from OOP. However, many of OOP's fans are very zealous, and tend to present OOP as a sort of cure-all. An interesting view point is presented on the pages Object Oriented Programming is Oversold [geocities.com] and Critique of Bertrand Meyer's Object Oriented Software Construction, 2nd Edition [geocities.com]

My impression is that the relational model of databases is more natural to most DBAs than the object oriented model. Object oriented software tends to have a large nunber of derived types, and furthermore operator overloading (or function overloading) makes it impossible to read a snippet of code and really know for certain what it does. For certain applications (e.g. management of large data sets and low level systems programming) these features do not provide a sufficient "win" to offset the additional complexity and overhead. The competing paradigms in programming language design that I think are most compelling are:

  1. Procedural languages (and assembly language) for precise control of the machine and mapping onto hardware.
  2. Functional Programming (e.g. LISP) for rewriting and filtering of inputs. Many scripting languages do some of this.
  3. OOP for providing transparent abstraction, encapsulation of data and programs, information hiding, and code reuse.
  4. Declaritive Languages (e.g. Prolog) for goal seeking programs using logical deduction
  5. Relational databases for large data set management and manipulation.
Remember that the art of picking the right tool is critical to doing a good job.

Because I haven't found a compelling reason to (2)

Anonymous Coward | more than 13 years ago | (#245630)

Whenever I've researched the topic, the canonical example returns to the infamous "bill of material" problem. While that is a good OODBMS application that RDBMS have problems with (although Oracle has extensions to help here...) I've never programmed one.

One way to look at OODBMS is the second coming of IMS, the old IBM hierarchial DBMS.

I do Java programming (I hear boos and hisses from the peanut gallery, but I persist...) and could use a seamless way to store state of my object hierarchies, but OODBMS haven't been it. (The wag will say at this point that I should be using Smalltalk, which has this seamless storage, but I duck this brick and go on my way).

Why aren't you using Oracle? (4)

Anonymous Coward | more than 13 years ago | (#245632)

Ok only one disadvantage with this OODBMS, a system wide recompile EVERY time you make a schema change. Umm, that's a pretty big disadvantage in my book.

Oh my god... (3)

pb (1020) | more than 13 years ago | (#245634)

Great job, Carnage4Life!

I didn't think I'd see the day when someone got actual content posted on Slashdot.

Or, for that matter, that you'd post a Java article that I thought was somewhat interesting and useful... :)

Anyhow, wouldn't it be easier to integrate all this with C? Especially considering the huge body of existing code, and the well-known primitives involved.

And are there any less proprietary OODBMSes out there that anyone would recommend?
---
pb Reply or e-mail; don't vaguely moderate [ncsu.edu] .

Blah blah blah. (2)

defile (1059) | more than 13 years ago | (#245635)

Most of my applications are insulated from the actual RDBMS. I usually define all of the data-primitives I'd have in a given project, and only make RDBMS calls from this layer. The application itself only makes calls against this layer instead of being burdened with directly operating on the RDBMS.

Besides being better for portability, it also means that the application isn't tied to the actual RDBMS. It can easily be made to speak to something that may naturally expresses it's dataset, if necessary. This is no small feat. It means that IT DOESN'T MATTER WHAT THE UNDERLYING DATABASE IS. It could be a freaking plaintext file or it could be something ludicrously complicated.

I'm totally not amused by the Objectify-Everything mindset. This is a very difficult perspective to have, FWIW. All academics teach OOP as the "one, true, way." and in practice, people believe them. In practice, they also find that it's not the silver bullet that it's trumped up to be. Regardless, saying that you think it's bullshit leads most people to the conclusion that you're an unwashed uneducated fool.

Oh well. I never accused programmers of being open-minded.

Re:it is worth it! (2)

sql*kitten (1359) | more than 13 years ago | (#245640)

Why do you think 19 out of the 20 biggest Telco companies use ObjectStore?

They don't use just Objectstore. Lots of them use Informix [informix.com] too - like 8/10 of the world's traffic if you believe the adverts.

It's more about Mainstream vs. Performance (2)

Juju (1688) | more than 13 years ago | (#245641)

First, I'd like to say that I work for Object Design (ObjectStore), so I am probably a little biased...
Although I had worked before on Oracle systems.

People have more confidence that they can find developers for Oracle than ObjectStore. But the same is true about COBOL programmers vs Java or C++ ones.
But this is why we have got consultants to help start the projects and get the design right. Once started on the right track, development usually goes a lot faster than in a traditional RDBMS environment.

I think the main reason people stick with Oracle and co. is that they prefer a known and tested solution like an Oracle database to store their business data.
This is the old "no one got fired for choosing IBM" argument.

By the way, there is no dba with ObjectStore (at least not in the way people think of them).
The optimizations are done by the programmers because the db layout is really dependant on your object model.

But the speed factor is something real which is why ObjectStore is doing so well with telcos (where speed is of the essence) with C++ applications.
On the EJB side, we really blow RDBMS out of the water. Oracle is nowhere near Javlin (EJB containers for ObjectStore) in term of performance...

it is worth it! (3)

Juju (1688) | more than 13 years ago | (#245642)

Why do you think 19 out of the 20 biggest Telco companies use ObjectStore? The answer is speed! I have never seen an app running faster on Oracle than on ObjectStore.

I agree about the complexity and skill availability arguments, it is still easier (and cheaper) to get several COBOL and VB programmers than Java or C++ ones.
But then you can always get a consultant to help with the design. And as a matter of fact, it will be faster to develop that way than having a bunch of COBOL developers put together some kind of server side app while some VB coders put the client interface together...
Having done both, I can tell you what kind of system scales and which one does not.

Have you done some EJB programming? You would be surprised how much faster and easier it is to go the OODB route.

My opinion on what the biggest problem really is, is mainstream recognition. OODB vendors are vulnerable to FUD from RDBMS vendors as much as Linux was suffering from Microsoft FUD two years ago. Note that for OODB systems (as for Linux 2 years ago) there are some good reasons to stick with the mainstream solution. Going the OODB route is far more risky (from a business decision making point of view).

Re:Ahhh, more FUD (2)

miniver (1839) | more than 13 years ago | (#245643)

Not only is there a standard but the ODMG standard is on version 3, JDO is merely a Java standard. Please know the facts before flaming.

Yeah, there's a standard ... but what good is the standard if none of the vendors do more than implement subsets of the standard, and none of the vendors implement the same subset?


Are you moderating this down because you disagree with it,

Oh, OODMS (1)

booch (4157) | more than 13 years ago | (#245646)

At first glance, I thought it said CONDOMS. I thought it was kind of a weird topic for Slashdot.

RDBMS w/ CORBA layer (3)

johnnyb (4816) | more than 13 years ago | (#245647)

Actually, data loading/backend-type stuff is easier with an RDBMS, because data-entry is almost alway tabular anyway. However, once entered, it is usually easier to process it through an OO layer. The best way to accomplish this is to have a CORBA layer that the applications always use for talking to the database that actually incorporates all the business logic, but have the CORBA layer talk to an RDBMS.

I don't have a lot of experience with OODBMSs - I'd be curious exactly how they work. The closest I've worked with is PostgreSQL which is Object-relational. Are there any intro guides, especially to schema definition and stuff like that.

Is there a free software OODBMS?

Performance? (1)

jbert (5149) | more than 13 years ago | (#245648)

The article says that 'impedance mismatch' causes performance loss. I don't see this as necessrily true. If anything, I'd expect the additional features (listed at length in the article) to cost performance...are any numbers available?

"No Primary Keys" is _not_ an advantage. (1)

armb (5151) | more than 13 years ago | (#245649)

Whether an OODBMS or RDBMS is more appropriate depends on the situation, (and how good the particular database implementations are - you can read lots of stuff by Codd on how what most people think of as RDBMS's has more to do with implementations that what the relational model actually allows (for example, the One Data Model fits there - operations and behaviour should be part of the single model, they just aren't usually part of the database schema). As a general rule if your data structures are stringly tied to a particular application, you want an OODMBS, and if you want free form ad-hoc queries and flexibily changing applications, you want an RDMS.
But anyway, I just wanted to pick up on one point.
When you say "No Primary Keys: The user of an RDBMS has to worry about uniquely identifying tuples by their values and making sure that no two tuples have the same primary key values to avoid error conditions. In an OODBMS, the unique identification of objects is done behind the scenes via OIDs and is completely invisible to the user." that's just flat wrong (and dangerously so).
Object identity is important. If you rely on invisible Object IDs to wave a magic wand and handle it for you, you will almost certainly end up with a single real life object having multiple inconsistent representations in the database, so to avoid screwing it up you will need to do explicit defining of keys and checking for duplicates.
On the other hand, if you have a well defined keys in your Relational Database, there isn't a problem - the database won't _allow_ duplicates. In a worst case, you have to define artificial IDs in your RDBMS and you are back to the OID case except that you actually have control over them.
Of course lots of people do make a mess of choosing keys - but OIDs _don't_ solve the problem.

--

I'll tell you why (1)

ajm (9538) | more than 13 years ago | (#245652)

No one ever got fired for buying oracle/db2. At the moment why would you bet the farm on a wonderful "new" (yes I know it's not really new) technology like this, especially when the previous incarnation of oodbms failed in the early 90s (I was involved with one of these, a complete disaster) when you can get nice object relational mapping tools and use a good and proven solution?

Schema Smema (1)

ArthurDent (11309) | more than 13 years ago | (#245655)

I was a database administrator for 3 years, and I think I changed the schema of an existing table exactly once. Now, I'm not totally sold on the idea of OODBMS, but if it has genuine benefits, then making schema changes harder would not be that bad considering how often they tend to occur.

Ben

Re:You didn't read the article, did you? (2)

esper (11644) | more than 13 years ago | (#245656)

Aren't you supposed to design an application before implemnting it in any way including putting data in a DB? I've worked at two companies and had a ton of projects in school and none involved implemnting the database before the application was designed.

So I take it you've only worked on pristine new projects coded in a vacuum, then? While I've never known anyone (well, anyone who knew what they were doing) to start putting data into a new database before designing their app, I've encountered many cases of new apps being written to use existing databases, generally either because the new version needs to be backwards compatible with the old one or because the need has arisen to look at old data in a new way.

If you only found "one" disadvantage, you ... (1)

Augusto (12068) | more than 13 years ago | (#245657)

... need to redo this "study".

Object databases are cool, specially from a programing standpoint, but there are a lot many disadvantages than the single one you listed, including : cost, familiarity (most people are not), less vendors (and open source alternatives), legacy databases (migrate or build bridges ?), etc.

Whenever you compare technologies, if you only find 1 disadvantage, you have probably not looked hard enough.

the most pragmatic reason i've encountered... (3)

dohmp (13306) | more than 13 years ago | (#245658)

was the ability to use already-existent tools to do data mining, reporting, & other similar (not necessarily insignificant) activities...

in all cases that we had gone through rigourous prototypes of products and used ODBMS', it always seemed to come down to the same few things:

1) critical mass (everyone already knew the relational databases very well)

2) tool robustness (there are a wide variety of good tools (most 3rd party supplied) to MANAGE relational instances. i'm referring to more subtle circumstances than managing users & schema here)

3) reporting and data-mining was ALWAYS more difficult (usually by an order of magnitude or more).

now, my last involvement in a prototype is YEARS ago, so i'm absolutely positive things have changed...

the reality remains that people haven't yet gotten by what they learned in their first few experiences and simply haven't re-examined the landscape, just like myself...

a weak excuse, but i'm certain this is a more common answer than we'd all like to admit.

just my 0.02.

Peter

Re:Hmm.. (1)

An Ominous Coward (13324) | more than 13 years ago | (#245659)

I'm fired... arn't I.


You should be, if you're a software engineer. If you're just a code monkey then it doesn't really matter as you don't create the design, just bang out code from a specification.

Re:Why not? I'll tell you why not . . . (2)

funkman (13736) | more than 13 years ago | (#245661)

The schema change is the biggest drawback. Adding to columns to a database is "simple". Adding fields to an object is not so simple. (OK it is simple, its the recompiling and ensuring all objects are correctly serialized etc is the pain).

Adding columns and design changes are fact of life. Until it is as easy and safe as relational - OODBMS apps will definitely be widespread.

When OODBMS store their data in an XML document style format is when OOBMS will take off since the dtd can be written with versions in mind and older objects can still be understood with relative ease.

Re:Why not? I'll tell you why not . . . (2)

Waldmeister (14499) | more than 13 years ago | (#245662)

Great article. At this point, it's the only article rated higher than 2 and that's fully deserved.

But I have some additional points:

6. The world is not object oriented. Even if oo is a usefull tool, it is no silver bullet.
7. RDBMS are proven technology and rather well standardised, OODBMS aren't. Currently there is a proposal for a standard (java data objects), but even that only addresses one plattform.

Re:Why not? I'll tell you why not . . . (2)

Tim C (15259) | more than 13 years ago | (#245663)

Everyone knows SQL; nobody knows OO.

Well, I don't know about anyone else around here, but I knew OO before I'd even heard of SQL.

I know that C, Perl, etc are still very popular languages, and deservedly so, but C++, Java, etc are also extremely popular. I think OO has been around long enough now for there to be little excuse for people not to know anything about it. They're even teaching it to the Physics students at my old university, fer chris' sake! :-)

(Although not until after I'd been forced to learn Fortran, mind you...)

Cheers,

Tim

Why OODBMSs did not take over the world (5)

geophile (16995) | more than 13 years ago | (#245667)

I am one of the founders of Object Design (now Excelon Corp.) We had the slickest OODBMS -- persistence was implemented by taking over memory mapping, (no "overloading the arrow operator"). It was the least obtrusive OODBMS. Other systems of the day required you to use different string libraries or forego C/C++ standard arrays (for example). Other systems arguably had better scalability or concurrency models.

As someone else has pointed out, OODBMSs require a very different skill set. The problem isn't that your typical SQL developer didn't have these skills. The problem is that the things were ever referred to as database systems.

If you walk into a potential customer selling a "database system", then the database guys come and hear what you have to say. They ask about SQL support and point-and-click development tools. They are going to be looking for very high levels of concurrency, at isolation levels below serializable.

Selling a "database system" meant that once we got past the early adopters, we were selling against Oracle and we hit a wall. What we should have done from day one was to sell persistence for C++. We did start out like this, e.g. trying to convince ECAD vendors to build their products on top of ObjectStore. That had some limited success because the customers knew that they needed persistence, but they were C/C++ hackers at heart, and an RDBMS was a poor compromise. A "database for C++ with no impedance mismatch" sounds great to someone writing a 3d modeler. We then went on to apply the same logic selling to satisfied RDBMS users without changing our strategy, and that's when things stalled.

That strategy was necessary in some ways, because we were venture-funded, and the VCs weren't going to be happy with a small niche. They wanted something that would get into every insurance company and bank. However, by aiming high and failing (by VC standards), we abandoned our natural market too soon and avoided becoming a small success in that market.

Re:why am I not using one? (2)

platypus (18156) | more than 13 years ago | (#245672)

In fact, zope's OODBMS, the ZODB is usable without zope, see
http://sourceforge.net/projects/zodb/

Why use an OODBMS (1)

Phill Hugo (22705) | more than 13 years ago | (#245674)

Firstly, they only really make sense if your applications are OO. Mine are now, I use Zope and its OODBM is amazing (supports transactions, versions, undo etc).

It keeps things elegant, tidy and dev time is slashed considerably (perhaps 40% of similar things in PHP/RDBMS from my experience)

If you don't try them, you'll never know.

http://www.zope.org

Re:Practicality vs Performance (3)

Brento (26177) | more than 13 years ago | (#245677)

While OODBMS were an obvious choice to me for performance and ease of programming, my consultants told me that finding Oracle talent was so much easier than finding Versant talent (for example) that I would be wasting time and money using OODBMS. This is especially true of DBAs.

And that's precisely the same reason it took Linux so long to catch on in the enterprise, and why it still hasn't invaded small to medium businesses with only 1-2 network-savvy people. I'd love to switch to Linux fileservers instead of upgrading our NT boxes to 2k, but since we can't find anybody with the appropriate experience to manage them when I'm not around, we stick with the point-and-click OS's. Don't flame me for the decision, I'm just stating why we don't always switch to things we all know are best. (Reminds me of OS/2 for some reason.)

How about a data storage example? (1)

badmonkey (29600) | more than 13 years ago | (#245678)

I would have liked to see some example code for storing data into the OODMS, anyone have any?

Main reason: (1)

Godeke (32895) | more than 13 years ago | (#245680)

The main reason our company has not used a OO database is that we have programs written in many languages - all of which can access the relational database via a common interface (SQL) into supported objects (recordsets) for every language we use. OODB's want to impose a class structure that may or may not be easy to support in a given language, and the overhead for such a class structure for say, a web page extracting data for display, would be excessive compared to running a SQL query and outputting the rows.

GOTO Considered Harmful (4)

hey! (33014) | more than 13 years ago | (#245681)

This reminds of the famous GOTO considered harmful issue.

Relational systems are useful for a wide variety of tasks specifically because they are limited in their expressive power. This limitation in their expressive power means that certain desirable properties are maintained.

The objects that are recognized in the relational programming model are scalars, tuples and tables. Most operations are closed on the set of all tables -- that is to say the take tables and produce tables. This means that you can compose operations in various kinds of ways and still have more raw material for further operations.

To take a more modern view of this: relational databases are about the reuse of facts. The process of designing a database is one of analyzing factual relationships so that eventually each fact is stored in one and only one place. This, along with the closed nature of relational operations, facilitates recombining these facts in various novel ways. I believe this is the source of the relational model's sustained popularity.

The cost is that the resultant model is not ideal for any single application. I believe this is the nature of the "impedence mismatch" -- you are dealing with an off-the-rack, one-size-fits-most-applications representation of data. Naturally, for complex applications with severe performance constraints, a more tailored representation is required.

I've never had the cash to hack around with OO databases, so I'd like to learn more. Do they support the kind of composition of operations that you get with relational systems? Presumably objects can be re-used in different applications, but how well does this work in practice?

Re:why am I not using one? (2)

costas (38724) | more than 13 years ago | (#245686)

I asked the same question on K5, but got no takers: has anybody played with ZODB outside of Zope? insights/impressions?

ObjectStore PSE Pro (1)

Percible (39773) | more than 13 years ago | (#245687)

I've had experience this term of using ObjectStore PSE Pro on an OODBMS course.. and I didn't like it much. The system itself is proprietary - which meant that I could only run the code in the labs with the software installed, and I couldn't take a copy home with me... The object types which can be stored within the database are limited.. for example, I couldn't store Vector objects within the database, which was quite annoying.. Bleh. Not much content to this post, just a vent about how crappy PSE Pro is, mostly.. ;)

Re:You didn't read the article, did you? (5)

Mr. McGibby (41471) | more than 13 years ago | (#245688)

Aren't you supposed to design an application before implemnting
it in any way including putting data in a DB? I've worked at two companies and
had a ton of projects in school and none involved implemnting the database
before the application was designed.


I'd like to know what world you are living in. In the real world, most databases
are legacy databases and FULL of data. I've had to design applications around
databases for years now. In my field (Programming for Engineers) the data is king
and people need to access it in multiple ways. True, if you are designing a
system from the ground up, then you will be able to design the DB and
make it nice and pretty. This is seldom the case in any case but web development.

This is simply hogwash. RDBMSs are by their nature
non-generic espoecially when one adds foreign keys and constaints to a system
which are necessary for any decent sized application. On the other hand the
entire point of object oriented programming
is creating generic reusable
components. With the ability to use inheritance and polymorphism in an ODBMS I
see no reason why you believe an RDBMS is more generic.


'Generic' may be the wrong word here. A better one would be 'simpler'. A lot of applications
just don't need all the OO stuff. The reason that RDBMSs are so pervasive is
because most data can be represented well and in an easy to understand way with
just tables and keys.

Learning
OODBMS techniques is mainly learning how to use another API in your bject
Oriented programming language of choice (well C++, Java or Smalltalk) versus
learning SQL and relational database theory. If people could learn SQL which is
completely unrelated to any other aspect of their programming experience then
adding OODBMS techniques as a skillset would be trivial. Of course, if people
don't realize that alternatives to RDBMSs exist then they won't learn these
techniques. That is more important because management can't find people who have
these skills if developers don't go out and learn these techniques.


Developers aren't the only ones who have to query the database. In my shop,
we have 10-20 people querying the same database. Many of whom have spent a lot
of time learning SQL. Most of the people who need to look at the data are
not able to pick up a new query language quickly enough. SQL is simple
enough to learn. RDBMSs are simple and easy to understand. With an OODBMS,
these people have to be trained on what the heck OO is. This is not an easy
concept for a non-progammer. On the other hand, tell someone that the database
is a collection of tables, and they can easily understand.

Now I just realized you didn't read the
article. People have measured gains in the range of ten to a thousandfold
increase in performance, these are not incremental. Secondly the primary benefit
is that it means you have to write less code and don't have to worry
about multiple paradigms at once when implementing an application.


Sure. I'll believe it when I see it. This sounds like marketing hype to me.
Sounds like someone who didn't know how to program for an RDBMS wrote some
crappy code. Correctly written code for an RDBMS would not experience these
kinds of gains when converted to an OODBMS. The overhead for the conversion
process could be this large, but only if the original code is crap.

Re:Oracle? (1)

Chandon Seldon (43083) | more than 13 years ago | (#245689)

Perhaps.... because Oracle isn't an OODBMS.

Re:Hmm.. (1)

paRcat (50146) | more than 13 years ago | (#245691)

Apparently someone didn't get the reference to The Simpsons episode 4F12.

oh well. I should never try to be funny again.

I wish there was one... for PHP (1)

Betcour (50623) | more than 13 years ago | (#245692)

Being a PHP coder I'd really love an OODBMS but then, amongst the few that exists, none of them can be interfaced with PHP. Most of them are geared at Java or C++ (which are much better OO languages than PHP) but then, that's not what many web developper use for their apps !

O/R Mapping Layers? (2)

dubl-u (51156) | more than 13 years ago | (#245694)

One interesting compromise is to use O/R mapping layers; you put all your data in a traditional SQL database and describe a mapping to objects.

A couple of interesting open-source ones are Castor [exolab.org] and Osage [sourceforge.net] . I haven't had the chance to use either one in a serious project yet, but as a NeXT refugee I'm looking forward to using a good O/R mapping layer again. Do people have any recommendations?

For those interested in the topic, there is useful information at Scott Ambler's site [ambysoft.com] , including his white paper The Design of a Robust Persistence Layer for Relational Databases [ambysoft.com] .

OODBMS issues (1)

theMAGE (51991) | more than 13 years ago | (#245695)

1. From the management perspective: RDBMS people are easier to find and there are more big iron Oracle installations that all OODBMS combined (my guess).

2. From the developer perspective: the overhead between of the OO layer on top of the database is known. What if I get a OODBMS with superb C++/Smalltalk integration but poor Java support?

There are certain design/implementation patterns that deal with OO/RDBMS impedance mismatch and the burden of reimplementing them for every project is accepted as a fact of life...

Don't forget Cache... (2)

1010011010 (53039) | more than 13 years ago | (#245696)

It has really spiffy Java Object Projection, and is a lot faster than Oracle.

http://www.e-dbms.com/


- - - - -

Re:Why not? I'll tell you why not . . . (3)

1010011010 (53039) | more than 13 years ago | (#245697)

Cache [e-dbms.com] solves some of the problems you point out. It's accessible relationally or via objects. New object interfaces can be added to existing ones, or to relational and non-relational data stores. So, Cache is generic. Complexity -- because Cache can also be accessed as a relational database, you can write a new Java OO app using its object interface and let older apps continue to use its SQL interface. Skills availability -- start relational, have the choice of trying OO.

- - - - -

Re:Why not? I'll tell you why not . . . (3)

1010011010 (53039) | more than 13 years ago | (#245698)

http://www.e-dbms.com/cache/components/cacheobject s/index.html

- - - - -

Re:Cuz it's just a BUZZWORD. (1)

Coy0t3 (62077) | more than 13 years ago | (#245701)

My favorite OS isn't coded mostly in C. BeOS is almost completely C++.

OODBMS have different goals (1)

const (62774) | more than 13 years ago | (#245702)

OODBMS systems usually state different goal from RDBMS. The OODBMS goal is an persistentce for object. This is an cardinal break from RDMS parspective, which goal is to provide interface to structured persistence storage. Lets consider full typical stack of layers in RDBMS. 1. hard drive or other physical persistence staroage (disk/sector model) 2. file system above hard drive (folder/document model). 3. structre above files (database/table/record model). All three layers provide different interface to the bits on the dist but throw different concepts. They update disks on bits and start from bits on the disk. OODBMS-es do not start from bits on the disk, they start from objects an make them "persistent". The goal is unreachable. Object is transient thing and could not be made peristent. If you will kill a program and start it again you will have other object. OODBMS system usually invest to many efforts to maintain the Illusion of Persistence, but the Illusion is broken on every step. A schizophrenical double thought is required to program on OODBMS-es. Object is persistent and transient at the same time. It is especialy hard to think in this way in clustered environment. OODBMS-es will start to conquire the world when they will acknowledge reality of transient objects and persitent bits on the disk. So task will be good OO interfaces to those bits. Only OODBMS' innovation that worth trees killed in name of them is OID (and therefore an fast navigation) and which could be easily put in the RDBMS. I guess that SQL3 (or SQL99) already done it. Inheritance is really syntactic sugar over linking. Composition is also easy with oids and cascade on delete. "No Impedence Mismatch" cost loosing flexibility in schema changes. One data model is easily solved by automatic generation of interfaces from database, database scheme model just need to be enriched with binding info. But database should be an real source of data model.

OODBS have different goal (1)

const (62774) | more than 13 years ago | (#245703)

OODBMS systems usually state different goal from RDBMS. The OODBMS goal is an persistentce for object. This is an cardinal break from RDMS parspective, which goal is to provide interface to structured persistence storage.

Lets consider full typical stack of layers in RDBMS.

  1. hard drive or other physical persistence staroage (disk/sector model)
  2. file system above hard drive (folder/document model).
  3. structre above files (database/table/record model).

All three layers provide different interface to the bits on the disk but throw different concepts. They update disks on bits and start from bits on the disk.

OODBMS-es do not start from bits on the disk, they start from objects an make them "persistent". The goal is unreachable. Object is transient thing and could not be made peristent. If you will kill a program and start it again you will have other object. OODBMS system usually invest to many efforts to maintain the Illusion of Persistence, but the Illusion is broken on every step. A schizophrenical double thought is required to program on OODBMS-es. Object is persistent and transient at the same time. It is especialy hard to think in this way in clustered environment.

OODBMS-es will start to conquire the world when they will acknowledge reality of transient objects and persitent bits on the disk. So task will be good OO interfaces to those bits.

Only OODBMS' innovation that worth trees killed in name of them is OID (and therefore an fast navigation) and which could be easily put in the RDBMS. I guess that SQL3 (or SQL99) already done it.

Inheritance is really syntactic sugar over linking.

Composition is also easy with oids and cascade on delete.

"No Impedence Mismatch" cost loosing flexibility in schema changes.

One data model is easily solved by automatic generation of interfaces from database, database scheme model just need to be enriched with binding info. But database should be an real source of data model.

Disadvantage: Lack of mathematical completeness. (1)

ryarger (69279) | more than 13 years ago | (#245705)

One *huge* area that the article did not touch on is the lack of mathematical completeness in an OODBMS system.

When I join two tables in an RDBMS, a presice mathematical formula can be followed to join the tables with great effeciency (especially with the existence of keys).

Let's take an extremely simple example: I have a Company object that contains an array of People objects. The People object contains among it's attributes, a Last Name field.

I want to find all the Company's that employ 'Anderson's.

The join required in an RDBMS to do this is simple and effecient. How is this performed in an OODBMS? Is each company instantiated and it's People array walked, searching for 'Anderson'? Ick.

OODBMS has it's place, particularly in tree-based systems, where ad hoc queries are rare (cf. Zope's content management system), but RDBMS has a fundamental advantage when dealing with large data sets and/or joins.

More disadvanatges of OODBMS's (1)

gradbert (80505) | more than 13 years ago | (#245707)

the object database had many more disadvantages when compared to the relational model than listed in the article above.
  1. Lack of a standard query language. With pretty much any relational database I know that there is a way I can sit at my computer, type SQL and get results. This is VITAL for any real world application as it provides a way to work with the database without having to write a custom application .
  2. no mathematical foundation of the data model. The relational data model has very strong mathmatical foundations. This gives me very powerful tools for looking at the diesign of the database and for optimizing queries.
  3. blurring the line between normal varible/object access and database access is probably a bad thing. where I work we had to be very consious of how much load we put on the database. we nned to know what will actually touch the database and what won't
  4. the real impedance mismatch is not between tuples and object. I have always flet that with the relational database that the real impedance mismatch came from the fact that a query against a relational database gives as its result a TABLE. unfortuanatly none of our programming interfaces to relational database will work that way. they all make you use a stupid cursor. in the java exaples above, notice the use of the iterator, the cursors younger brother

Good, but somewhat misleading (2)

figlet (83424) | more than 13 years ago | (#245709)

This is a good article, but only presents 2 extremes in the examples (in Java): either use a native OODBMS, or use raw JDBC. The latter is not how anyone doing any medium-to-large scale projects. Instead of using "raw" JDBC to talk to an RDMS, object-relational middleware (like "TopLink", etc.) are used to map the objects to the tables transparently to the programmer. So, you can have code which looks like, and is as easy to understand/use, as the OODMS code in the example, but the back-end is a RDMS.

Just check out what google(tm) gives you for the search terms: object relational mapping [google.com] .

yabba

Vendor lock-in (1)

trcull (83999) | more than 13 years ago | (#245710)

I don't think the effect of vendor lock-in can be underestimated. Until there's a standard for accessing and bulk-loading/querying OODBMS like JDBC or ODBC, we're not going to see wide adoption of them for several reasons:

1) If your database isn't performing up to snuff, you can't switch to another vendor without re-writing tons of code.

2) If you need to integrate with another piece of software (ie. your company just bought another company and wants to incorporate that company's product into its own) you're out of luck.

3) If you have a large volume of legacy data you need to roll over into your system, loading it in and querying it will be a painful exercise.

We have a home-grown OODBMS-ish system at my company that we have to build our systems on and consequently it is very painful to integrate with anything from the outside world.

this means nothing to me (1)

Dalroth (85450) | more than 13 years ago | (#245711)

This really means nothing to me, and here is why. If I were to even consider an OODBMS, it would have to be Open Source AND accessible from C++, Java, Perl, Python, you name it. Every where I look, just about every OODBMS is Java Java Java Java Java. Well, hello? The world isn't all about Java. I do plenty of work in Java, but I can't sacrifice support for other languages. I don't see any open source solutions that cross the language boundary.

Re:Blah blah blah. (1)

radish (98371) | more than 13 years ago | (#245713)


Most of my applications are insulated from the actual RDBMS. I usually define all of the data-primitives I'd have in a given
project, and only make RDBMS calls from this layer. The application itself only makes calls against this layer instead of being
burdened with directly operating on the RDBMS.

Besides being better for portability, it also means that the application isn't tied to the actual RDBMS. It can easily be made to
speak to something that may naturally expresses it's dataset, if necessary. This is no small feat. It means that IT DOESN'T
MATTER WHAT THE UNDERLYING DATABASE IS. It could be a freaking plaintext file or it could be something ludicrously
complicated.


I'm not so sure what makes you feel so superior, doesn't everyone do this? You're not getting the difference here. In your model, you may be going against any old DB, but you're still accessing (and thinking of) your data in the same old tabular way. An OODBMS totally changes your way of thinking. If you try and use an OODBMS in the exact same way as an RDBMS you will most likely hit problems, not least with performance. But if you were to adjust your thinking to using an OODBMS properly you would see some amazing things start to happen.

I've never used a real OODBMS, but in a project I was recently on we built an objectrelational mapping layer which attempted to do more than the usual. Rather than allowing us to build & populate individual objects from the DB one at a time, we could specify (at run time) a query. This would be run against the backend DB and the mapping layer would look at the data and create all the objects it could from that data set, with allowances for mandatory/optional fields etc. So for instance you could do something like "select * from customers, orders where order.value>1000" and you would get back a set of order objects where the value was over 1000, and also the appropriate customer objects. All the inter-object references would already be populated and if you asked for something which didn't exist (maybe order.getProduct()) it would go off and build it for you.

In short this approach (and I'm sure real OODBMS systems do this better) allows you to change how you think about the data, often with great results.

Re:Too Much Integration (1)

Lacutis (100342) | more than 13 years ago | (#245714)

Not really, you should be able to figure it out with a variation of the first java example (In the language of your choice, of course).

Once you have the hash table of objects, you should be able to print them out and then be able to work with them.

Ahhh, more FUD (3)

Carnage4Life (106069) | more than 13 years ago | (#245717)

6. The world is not object oriented. Even if oo is a usefull tool, it is no silver bullet.

Which makes more sense when writing an application using an object oriented programming language to develop an application? Using a database that is consistent with the programming paradigm and performs database operations transparently or one that requires the developer to go through additional hoops to get data, is generally slower, and involves writing more code?

7. RDBMS are proven technology and rather well standardised, OODBMS aren't. Currently there is a proposal for a standard (java data objects), but even that only addresses one plattform.

Not only is there a standard but the ODMG standard is on version 3 [odmg.org] , JDO is merely a Java standard. Please know the facts before flaming.

--

You didn't read the article, did you? (4)

Carnage4Life (106069) | more than 13 years ago | (#245718)

Hi, thanks for the responses, I didn't think anyone would be done reading it so quickly. :)

Complexity. These systems are much more difficult to design than RDBMS. The application must be designed first, then the data structures must accomodate that. This kind of design is very expensive.

Aren't you supposed to design an application before implemnting it in any way including putting data in a DB? I've worked at two companies and had a ton of projects in school and none involved implemnting the database before the application was designed.

RDBMSs are generic. Since an OO system is designed for a specific application, it's difficult to use that system for anything else. A well-designed, properly normalized RDBMS can be used for many different applications. When a DB is going to fill many terabytes, you don't want to have multiple copies of it for each distinct reporting application.

This is simply hogwash. RDBMSs are by their nature non-generic espoecially when one adds foreign keys and constaints to a system which are necessary for any decent sized application. On the other hand the entire point of object oriented programming is creating generic reusable components. With the ability to use inheritance and polymorphism in an ODBMS I see no reason why you believe an RDBMS is more generic.

Schema changes. As mentioned in the article, schema changes are a nightmare with an OO system. In a relational system, some changes can be made with no impact on existing applications. Others are relatively uncomplicated compared to similar OO changes.

...and in an OO system some changes can be made without no effects on the existing applications. In the general case though an RDBMS is more flexible than an ODBMS.

Skills availability. Yes, the old management problem. Everyone knows SQL; nobody knows OO.

Learning OODBMS techniques is mainly learning how to use another API in your bject Oriented programming language of choice (well C++, Java or Smalltalk) versus learning SQL and relational database theory. If people could learn SQL which is completely unrelated to any other aspect of their programming experience then adding OODBMS techniques as a skillset would be trivial. Of course, if people don't realize that alternatives to RDBMSs exist then they won't learn these techniques. That is more important because management can't find people who have these skills if developers don't go out and learn these techniques.

It's just not worth it. Given the dramatically higher costs associated with designing and maintaining an OO system, most applications just don't need the incremental performance gains associated with it. Very specialized, very high performance systems would benefit, but smaller or more general systems would not.

Now I just realized you didn't read the article. People have measured gains in the range of ten to a thousandfold increase in performance, these are not incremental. Secondly the primary benefit is that it means you have to write less code and don't have to worry about multiple paradigms at once when implementing an application.

Finally, where the heck are you getting this BS that designing an application with a single data model (i.e. one set of UML diagrams) is more expensive than designing one with 2 data models (i.e. an ER model for the DB, UML for the application).

--

Re:Try generating reports on an OO database! (1)

BinxBolling (121740) | more than 13 years ago | (#245720)

My experience has been that: The accounting people who wanted to generate reports using the tools they were used to (Crystal Reports, Excel, etc.) needed instead to ask the IS department to write programs that would generate flat files (rows and columns) so that the complex, non-tabular OO data could be brought back to tabular data for reporting purposes. Hell it would have been simpler and cheaper to have had the data in an RDBMS in the first place!

An RDBMS wouldn't have necessarily made reporting any easier. The sort of highly-normalized RDBMS schema that is appropriate for an OLTP-type application is quite hard to report against - data in such a schema isn't usually very "tabular", either.

Many shops that use an RDBMS for their OLTP systems end up building a seperate data warehouse with a flatter, more tabular schema that can be more easily queried for report generation.

Speed? Reliability? (1)

Jason Cwik (124849) | more than 13 years ago | (#245724)

Is there a standard benchmark out there? It would be interesting to compare the speed of the OO databases vs. traditional databases because you know that IBM and Oracle have spend years tuning their databases for speed and reliability.

On the topic of reliability, what about advanced DB features such as replication? Can I have ADSM log into the database and do a hot backup?

Of course then you have the age old issue of a company saying "We run DB2. Period." Then choosing an OO DB is a moot point...

Price? Tools? (1)

TheLink (130905) | more than 13 years ago | (#245729)

Where can I get a cheap/free OODMS?

Then from the "cheap OODMS" subset, what are the OODMS which have interfaces with Python/Ruby/other scripting language?

If the result is zero, then maybe that's one answer to "Why aren't you using an OODMS?".

Of course there are other things to "constrain" the query on like docs, examples, mailing lists.

Cheerio,
Link.

Re:More disadvanatges of OODBMS's (1)

TheLink (130905) | more than 13 years ago | (#245730)

"the real impedance mismatch came from the fact that a query against a relational database gives as its result a TABLE"

Just write a function/method so that given an SQL, you get a list/array of stuff.

Of course that uses more RAM - everything loaded into program's memory space. Oh well :). Maybe could offset that by configuring things to reduce the DB/DB interface result buffer - that's what the DB interface's iterator or whatever usually steps through anyway.

Cheerio,
Link.

No solid foundation (1)

kill -9 $$ (131324) | more than 13 years ago | (#245732)

I think the main problem with OODMS is there is no consistancy to the design of them. You have two schools of thought basically, extended-relational the (path the major RDB vendors take for fairly obvious reasons) or to build a new foundation as as O2 (out of business), ObjectStore (I believe) and other folks have taken.

IMO, extended-relational has the best chance at success because at its core you have the solid relational mathematics developed by Codd so many years ago (a solid starting point). But has anybody used the OO features of Oracle 8i for instance. I have, and I thought it sucked. It seemed all they did was put an OO interface on relational tables. You could still access OO data via standard SQL so you couldn't guarantee encapsulation, etc. and all the other great promises of the OO paradigm.

I've also used O2. Very interesting appproach, but hardly solid. (and as I've mentioned, they've gone out of business) Each vendor builds the quailties of an OO database they feel are necessary and there is no consistancy among vendors (as in the RDB world). Products are either significantly immature, lack serious qualities required for a production DBMS, or just plain don't work. (Note: I don't necessarily think this is a bad approach to the design of an OODB, in that I felt these types of products preserved a lot of what OO was trying to do. Its just that nobody has been able to define an concise, solid theory (like the relational model) upon which to build these products)

So to answer the question, why don't I use a OODBMS? Simply because the technology isn't superior to my existing RDB yet. Only in certain niche solutions (engineering, BOM's, etc.) might I actually consider using such a product. I feel its a straight-forward example of right tool for the right job.

Other OODBs (1)

BMazurek (137285) | more than 13 years ago | (#245735)

GOODS [ispras.ru] is another OODBMS that I have seen mentioned.

SAL [kachinatech.com] has listings of a bunch of OODBs.

Re:Why not? I'll tell you why not . . . (2)

BMazurek (137285) | more than 13 years ago | (#245736)

I'm sorry, I don't understand many of your arguments. (Disclaimer: I never really used either OODBMS or RDBMS.)

These systems are much more difficult to design than RDBMS. The application must be designed first, then the data structures must accomodate that. This kind of design is very expensive.

Don't system designs using UML or any modelling technique used today translate quite simply to an OODB, since they are OO to start with?

The application must be designed first...of course, on successful projects people don't immediately start coding without knowing what they're coding. I don't see how that differs depending on an RDB or OODB world...

Since an OO system is designed for a specific application, it's difficult to use that system for anything else.

Isn't that like saying you can't use the RDB you designed for project A on project B? It seems to me if you can move tables representing objects from project A to project B, you should be able to move the objects from the OODB used in project A to project B. The transportability of the objects OR tables depends on the relationship/similarity between the two projects.

I don't understand what you mean by multiple copies of an multi terabyte OODB....

In a relational system, some changes can be made with no impact on existing applications.

If changes can be made to the RDB tables without impacting the system, can't correspondingly similar changes be made to the OODB object models? If code has to change in one, it would seem to me that code would have to change in the other.

Everyone knows SQL; nobody knows OO.

Can't argue with that. Reminds me of a quote from a book that went something like this: "Like it or not, SQL is intergalactic interspeak."

As I said, I'm not very familiar with either, and any clarification of your points would be appreciated.

Warn Modem Users (1)

ekrout (139379) | more than 13 years ago | (#245737)

I think you should warn modem users (or other low-bandwidth surfers) that this page, with its long story and probably 200-300 comments by tonight, is one that they should stay away from!

Reasons for NOT going OO (1)

Cestus (141759) | more than 13 years ago | (#245740)

I work at a large telecommunications company and I work on a very large (understatement) database with billions of records loaded daily. We employ the eXtreme Programming [xprogramming.com] model for development. Our database is a release database and we modify it weekly. Adding new features, tables. Changing things as we go. As long as we control the interface changes are 'cheap' in cost. I shudder to think of how all these changes would be under an OO database. If you plan on using an OO database, you are basically cut out of the xprogramming style. You spend MUCH more time in 'designing' and less time 'delivering'. Thanks, but no thanks.

Why not OODBMS? Perhaps immaturity... (1)

jpietrzak (143114) | more than 13 years ago | (#245741)

I've had a long, and tortured, relationship with object-oriented databases. First, in college, I worked on a project to develop a software reengineering environment; source code was parsed and stored persistently in an Objectstore database. Unfortunately, at that time Objectstore was apparently still young, and their DB had a variety of bugs. The effort taken to adapt to and work around these flaws eventually monopolized, and then consumed, the resources availiable to the project. Perhaps Objectstore has worked out these problems by now, but it left a bad taste in my mouth.

I went on to work at a job involving a similar product, which stored data persistently in a Poet OODB. Although the basic functionality of Poet seemed to work correctly, my manager had chosen Poet in order to use a special feature that had been advertised, but (as it turns out) wasn't completed at the time the DB was released. Support e-mails turned into intercontinental discussions with the German developers of the product, weeks turned into months, and before long this project was a year behind schedule, due almost solely to a dependence on an OODB. Finally, Poet modified their licensing scheme (forcing potential users of our project to absorb exorbitant sub-licensing fees), and that broke the back of the whole effort.

I moved on to a new job at a large information services company. Here, they've been using Objectivity internally for some years, but we're now in the process of converting over to Oracle. Problems with scalability, with bugs, with support, and with licensing has driven the company to look for alternatives.

In short, I have no arguments against the underlying technology of OODBMSs, but I have yet to find an OODB company that can execute well enough to make their product worthwhile.

--John

OODBMS Hiccoughs (1)

theProf (146375) | more than 13 years ago | (#245745)

Well, I was involved for a while in a project that used an OODBMS. O2 in fact -- a product that was, last I looked, discontinued.

Problems with OODBMS

1. OQL implemations
2. dont' share data so well because most
are file-based implementations NOT servers
3. schema
4. administration

O2 worked, but the schema issue turned into a problem. Same sort of thing as versioning interfaces in CORBA. Every time an object is changed, Phoof.

OQL implementations are not particularly well done. Some systems do, some don't. And the variation in these is wide.

Administrative tools for a application on the OODBMS we used had to be written as part of the project. Reporting out of a OODBMS data set of course needs you to write more code. You cannot just use a copy of Access or similar.

You do not have a tidy client-server relationship across the wire in most of the products I checked out. There was one, but it cost $50,000. so you have to host the OODBMS on the same server as the application. Unless you care to get into CORBA or other 3rd party wire protocol.

Oh, and there are few 3rd party tools around for them.

OODBMS really must /not/ be confused with SQL datbases. They are not implimented in anything like the same way. And they have a very different set of costs.

My 1/2 penny worth.

Another disadvantage... (1)

jmichaelg (148257) | more than 13 years ago | (#245746)

The idea of object abstraction is nice but you really should know whether the object is in memory or on disk for the simple reason that going to disk costs a lot of time. Your initial design should take that simple fact into account so when you release, you're not shipping pig-slow software. Kinda makes you look bad in the marketplace.

Way back when, I worked on a new-fangled air-defense system that was going to be 100% high level language - no assembly language for us, no-siree! The machine was state of the art - 16 mhz with 24 terminals hung off it - power to burn! Fortunately, my boss had the sense to write a small snippet of code that pretended to be a radar feeding a control program - classic client-server code. No real radar processing was involved and the control program didn't have to do anything with the fake return except count it. Our design spec called for handling 2000 returns per minute. The simple client-server code he wrote could only manage 500 returns/minute. Fortunately, the test happened early in the coding phase so we were able to re-design portions of the system to adjust to the physical realities of the hardware.

Abstraction is nice but be sure it's not so abstract that the hardware can't handle it.

standards, compatibility, performance (4)

_|()|\| (159991) | more than 13 years ago | (#245747)

Dare has completely avoided the most important issue: compatibility. I work for a company that produces a DBMS that is marketed as "post-relational." It is, in fact, a hierarchical DBMS with a relational layer and a separate object data management layer. (The relational and object layer are linked by the conventional class-table, object-row, attribute-column mapping.) The object database is the strategic offering, with a proprietary scripting language, proprietary COM and Java bindings, and a proprietary web "server pages" technology. (If you think I'm using "proprietary" as a dirty word, you're right.) The relational database is still the money maker. We get "relational refugees" from Oracle and Sybase. We have a LAMP (Linux, Apache, MySQL, PHP) customer replacing MySQL with our ODBC interface.

As patchy as the SQL, ODBC, and JDBC standards may be, they have commoditized the DBMS market. Until object databases can do the same (the ODMG standards [odmg.org] don't even come close), they lock you into a proprietary solution. Ultimately, if your database doesn't scale as well as you'd like, that will hurt performance.

Research and Problems (1)

addbo (165128) | more than 13 years ago | (#245748)

OODBMS's promised to be the holy grail... a revolution as big as relational algebra for the database realm... current implementations of OODBMS's have certain diffieciencies(sp?)... from what I've seen these diffieciencies may soon be solved... but a major drawback is the loss of the set at a time data manipulation capability that can be had in RDBMS's... that could be due to the way we view OODBMS's or maybe the fact we don't yet have a language that properly defines all the data manipulation and/or data definition. There was recently some research I read done by a grad student at the University of Alberta in Edmonton... it was his disseratation actually... in it he defines a "type system for an object oriented database programming language" link can be had here: http://www.ualberta.ca/ExpressNews/news/2001/02140 1.htm his personal webpage here along with the link to his dissertation: http://web.cs.ualberta.ca/~yuri/ It is a 247 page disseratation so if you thought the parent article was long... then you probably don't want to tackle this... but it is quite interesting... addbo

Re:Cuz it's just a BUZZWORD. (1)

shippo (166521) | more than 13 years ago | (#245749)

The biggest problem is the resource overhead.

At work I use a system that sends financial transactions over an IP connection, writing them to an RDBMS. Depending upon the configuration this consists of between 3 and 5 processes per environment. Each process consumes a minimum of 6MB. but I've seen processes of 400MB in size, caused by handling a modest number of transactions. Everything is coded in C++.

10 years ago, the entire system would probably run as fast on a machine with a total of 6MB of RAM. Progress?

Sorry, but I've never been convinced by OOP. There is too much abstraction between the source code and the processor.

WebObjects and Oracle (1)

TeamSPAM (166583) | more than 13 years ago | (#245750)

As I have seen mentioned "Nobody gets fired for using Oracle" and I have yet to seen anything that will run faster than Oracle. Honestly if you have the money, I can't see a reson not to go with Oracle. It's fast, it will scale, and you can find talent to help you tune it.

At my job we use WebObjects [apple.com] to go the OO route. This is NeXT technology that Apple bought. One of WebObjects features that is very nice is EnterpriseObjects. I can suck in an existing database schema or create my own in eomodel and all my table become objects that I can use. Granted there is a layer between my code and the database, but I never put a line of SQL in my code. Usually all I do is make calls to accessor methods to get or modify the EnterpriseObject which is the data from the db.

This is something our DBA thinks is a slighty bad thing. If I have data in 2 seperate DBs, I can use eomodel to connect that data up and display it to the user. The really cool part to this is that they don't even have to be the same kind of db. You can mix data from Oracle with DB2 or SQL server. With a database abstraction layer this powerful why should I be using a OODBMS when I've yet to see them have the same performance of a powerful RDBMS like Oracle?

Another reason (1)

decesare (167184) | more than 13 years ago | (#245751)

To abuse an old quote: "No one ever got fired for buying a database from Oracle."

I used to work for one of the OODBMS firms mentioned, and a lot of our customers at that time were universities and a few companies doing small pilot projects with the database. But if you're an IT manager doing a serious database project, which vendor are you going to choose: a multi-billion dollar company like Oracle, or a relatively tiny OODBMS vendor that might not be around in a few years?

Sounds more like an ad.. (1)

hask3ll (171878) | more than 13 years ago | (#245753)

This piece sounds more like an ad than a real research paper. There aren't any real numbers, just the assertion that an OODMS can be faster on complex datatypes than an RDBMS. In what *specific* cases is an object-oriented database faster ? Then there's the "statisfied customer" section, "All these people are using object-oriented databases..."

The code size comparison is pretty useless. The code I use with Apple's EOF is more compact than any example here, and it can accomodate any kind of DB.

I'm sure that there are times when using an OODMS is a good choice. This article does nothing to help me determine what those times are.

Re:I concur... (1)

dannywyatt (175432) | more than 13 years ago | (#245756)

This is exactly the point I wanted to bring up. People have discussed sets and relations since long before computers existed. The math behind them is solid and well-understood (if you didn't sleep through Discrete Math).

While "object" math could get there, it hasn't yet. And, since we're all angelic coders who wouldn't think of deploying software that we hadn't proved computationally correct, how do we prove computational correctness of OO-data?

At least with relational-OO "mapping" we can prove that what we lose in the mapping is inconsequential to the application at hand.

Re:Too Much Integration (1)

Coz (178857) | more than 13 years ago | (#245758)

If your software design is OO, then to store data, you're having to disassemble what can be complex OO relationships, "flatten" them, and store them into relational tables. With an OODBMS, you can have your objects "store" themselves. The problem's even more complex when you look at reassembling objects from relational tables - the famed "impedance mismatch" that my friend Thad Scheer is always talking about.

One of the issues I've argued with OODBMS vendors is how to do ad-hoc queries. Some of them provide SQL interfaces to let you access the OO database, meaning they're mirroring their OO structure with a relational structure - but the query responsiveness always bites. Just don't try to do complex joins - they ain't worth the effort (yet).

As for reusing the database - if you have access to the object model, you can reuse the database - and each vendor has their own ways to make different parts visible to different applications.

I concur... (2)

motek (179836) | more than 13 years ago | (#245760)

From my point of view, there is an additional reason.
Theoretical rudiments for relational databases do exist and are well understood by some. I am not referring to SQL here, but rather to math.
Term 'relation' is well defined. Math behind it is pretty and simple. Simple is good.
So, on the one side we have well defined mathematical concept that can be worked on. On the other hand - elusive 'art of objects'. Although I personally prefer the latter (makes me feel good about myself) I always appreciate ability to define software in more solid terms. A relational database engine (what it does, what it needs to do) can be defined in terms of quite comprehensible algebra.
There are similar efforts for OODBMS (evolving algebras, for instance) but these are relatively recent - and most people doesn't care about them.
Conclusion: relational database engines are simple in construction. OO databases are not. Simple is good. Complex is bad. Long live RDBMS.

-m-

KISS Principle (2)

Alien54 (180860) | more than 13 years ago | (#245761)

With increasing levels of complexity you get increasing levels of functionality. You also get more things that break. You have to make sure that the underpinningsa are set correctly. When they are not, then watch out.

[Insert snide comment here] Take a look at that pinnacle of Object Oriented Programming, Microsoft Office

That cheap shot aside, The ramp up to a level of truly competent understanding is much longer than anticipated. The problem is that often OOP can give the appearance of competancy to those not in the know, but you still have the same problems that you had before, that can be much more difficult to find, if you are not expert

Check out the Vinny the Vampire [eplugz.com] comic strip

Re:I'll tell you why (1)

cnkeller (181482) | more than 13 years ago | (#245762)

True, but many companies have gone broke paying exorbitant licensing fees to Oracle.

Versant is fairly well used in the government sector (where due to budgeting constraints, they are often forced to use other than industry standard solutions). There have been numerous succesful implementations of OODBMS (Versant specfically), you just don't hear about them because they're not high profile commercial applications. Chicken and the egg right? Until a big name (Yahoo, IBM, MS) creates a highly publicized project incorporating OODBMS, you're going to have to do your own searching to find the "proven" successful projects who have done this. The ones I'm most familiar with are all classified applications, so Joe Programmer isn't going to ever hear of those...

Re:Practicality vs Performance (1)

nooekanami (192720) | more than 13 years ago | (#245765)

So if the tool/technology isnt popular, there arent enough people who are familiar with it. And OTOH, if there arent enough people familiar with it, the tool doesnt gain popularity :)

Thanks... (2)

ChaoticCoyote (195677) | more than 13 years ago | (#245767)

...for proving my point. ;)


--
Scott Robert Ladd
Master of Complexity
Destroyer of Order and Chaos

Re:I don't have enough Objects (2)

sv0f (197289) | more than 13 years ago | (#245768)

Now then, if you managed to find a language whose native types were *all* expressed as objects, where my data were all most naturally expressed as an object

Eiffel? C#? How about the originial -- Smalltalk.

(god bless Objective C and Scheme)

I don't know much about Objective C, but Scheme? In no sense are, for example, numbers treated like OOP objects in Scheme. I mean, you can't subclass them. They are objects in a non-OOP sense, I guess -- you can query their type and all. But this sense is irrelevant to the current thread.

Re:Ahhh, more FUD (2)

sv0f (197289) | more than 13 years ago | (#245769)

Which makes more sense when writing an application using an object oriented programming language to develop an application? Using a database that is consistent with the programming paradigm and performs database operations transparently or one that requires the developer to go through additional hoops to get data, is generally slower, and involves writing more code?

How about using the appropriate paradigm for the application at hand (which is not always OO), the right paradigm for the data in the database (which may be relational, OO, etc.), and establishing a sensible protocol between the two?

The point of your target article is well-taken, but don't get too religious about OO. uniformity for uniformity's sake is seldom convincing.

Re:Warn Modem Users (1)

dxfreak (197816) | more than 13 years ago | (#245770)

Get a Life, get fiber to the door !

Re:why am I not using one? (1)

mark_lybarger (199098) | more than 13 years ago | (#245771)

did ya look at the list of examples on the page? i haven't used it's db at all, but supposibly zope contains an oodbms (among other listed above)..

Why not? I'll tell you why not . . . (4)

micromoog (206608) | more than 13 years ago | (#245776)

From a purely academic standpoint, OO database systems seem like a better solution. They are elegant, and designed to integrate perfectly with the application. However, most of the reasons for using them are also the reasons for not using them:
  1. Complexity. These systems are much more difficult to design than RDBMS. The application must be designed first, then the data structures must accomodate that. This kind of design is very expensive.
  2. RDBMSs are generic. Since an OO system is designed for a specific application, it's difficult to use that system for anything else. A well-designed, properly normalized RDBMS can be used for many different applications. When a DB is going to fill many terabytes, you don't want to have multiple copies of it for each distinct reporting application.
  3. Schema changes. As mentioned in the article, schema changes are a nightmare with an OO system. In a relational system, some changes can be made with no impact on existing applications. Others are relatively uncomplicated compared to similar OO changes.
  4. Skills availability. Yes, the old management problem. Everyone knows SQL; nobody knows OO.
  5. It's just not worth it. Given the dramatically higher costs associated with designing and maintaining an OO system, most applications just don't need the incremental performance gains associated with it. Very specialized, very high performance systems would benefit, but smaller or more general systems would not.

Re:You didn't read the article, did you? (1)

Placido (209939) | more than 13 years ago | (#245778)

I'm not going to attempt to answer all of your points listed above. Just the first one.

Aren't you supposed to design an application before implemnting it in any way including putting data in a DB?

Yes you are. The data for the application should be analysed and the database designed around the data. Unfortunately in the real world dumb ass managers and accountants are <%do while foresight < average%>very, very, very <loop> reluctant to spend alot of money on the proper design and development of systems. Not only does this prevent the use of expensive-to-implement and expensive-to-support products but it also means that system designers do not have the time/budget to forsee all the changes that the data will go through. This means that almost every single database is not configured correctly and goes through many schema changes in it's lifetime. As with everything in life it is a balance between financial limitations and desired result.


Talking about financial limitations and desired end result, I desired a porsche but financial limitations prevented this... all I got was this lousy t-shirt.


Pinky: "What are we going to do tomorrow night Brain?"

I don't use OODMS (3)

stille (213453) | more than 13 years ago | (#245781)

Because I'm too lazy to read 21846 bytes of text that explains why I should.

Re:Why not? I'll tell you why not . . . (2)

WinterSolstice (223271) | more than 13 years ago | (#245783)

Here's another example for your case against OO: We implemented Poet, (at no small cost, I might add) only to find that within 6 months of beginning to use Poet as our major DB, a major 'Organizational Re-Adjustment' and a 'Data Center Consolidation' project wiped the whole dang thing in favor of DB2/OS390.

Now, our DB2 performance is actually much better than Poet ever was. Perhaps this is due to having highly skilled DB2 DBAs, or something. All the same, it is not worth going to a very expensive, single application db. Always use something standard, flexible, and easy to find admins for. It's worth it in the long run.

-WS

Oracle? (2)

NineNine (235196) | more than 13 years ago | (#245788)

Is there a reason that Oracle wasn't in the list of OODBMS? It's only the most used database in the world...

And the reason I'm not using it yet is because it simply hasn't been around long enough. Oracle's implementation from what I understand is still a bit buggy. The RSBMS version has been around for muuch, much longer, and when you're dealing with enterprise-class applications, you sure as hell don't want to use anything that's even close to bleeding-edge.

Because, where can we find the guys & the time (1)

ishrat (235467) | more than 13 years ago | (#245790)

This typically means that all schema changes in an OODBMS will involve a system wide recompile. Also updating all the instance objects within the database can take an extended period of time depending on the size of the database.

This seems reason enough to me.

Relating The Object (2)

grovertime (237798) | more than 13 years ago | (#245791)

I appreciate the merit and advantages to object databases over relationals, and the code example was an eye-opener. Still, how do I transfer over simply? Every coder and his dog is familiar with relationship databases, but how prevalent is object....anybody?

  1. what the? [nowjones.com]

Re:RDBMS w/ CORBA layer (1)

yzxbmlf (238008) | more than 13 years ago | (#245792)

You have to be careful with this approach with regards to performance. The data model is usually too fine grained to be exposed as distributed objects. The CORBA layer should be very course to reduce the load on the network.

Where are all the DBAs here? (1)

CrazyLegs (257161) | more than 13 years ago | (#245797)

I work for an evil multinational financial institution that does a ton of OO-based, client-server (or shall I say, network computing) apps. We've looked at OODBMS from time to time and shied away from them as a vehicle for large corporate apps. The reasons:

PERFORMANCE: They just don't perform for high-volume, on-line, real-time situations. Period.

TOO CLOSE TO THE CODE: The structure and nature of OODBMS stores forces too much thought from the Developer's perspective (consider the impact of object deep copies). We prefer to keep a cleaner line between database design and code access.

VISIBILTY OF DATA: A golden rule of Data/Function placement to put the data in a place (logical and physical) where it has the most visibility to its users and potential users. Fact is, it's tough to put an OODBMS on a boring old S/390 box - and I haven't seen a Unix or NT cluster that can take its place (even if they can house an OODBMS).

FUTURE APP USES: If I implement an OO app that uses an OODBMS, I know it works today. But the next app that comes along and needs to access that data may not be OO and may not be able to access the data.

OBJECT FIDELITY: Dumb problem.... but if the objects I store atrophy (i.e. the classes from which they're derived change), then I have a versioning problem. Sure there are ways to mitigate this problem through sound design, careful mgmt, etc. - but it's more crap to worry about.

Bottom-line for this kind of corporate computing environment is that OODBMS is a problematic technology. It forces too much up-front code design and doesn't provide enough long-term flexibility.

Ok... now tell me where I'm wrong (and you're probably right).

All that code makes my head hurt (2)

typical geek (261980) | more than 13 years ago | (#245798)

Hey Rob, could you not post such code heavy topics on a Friday? I'm still caffeine deficient, burnt from the week, and I'd like a lighter, funnier /. to get me in the weekend mood. Save this stuff for Monday, and put up some Katz or Star Wars stuff.

Its all marketing hype (1)

boltar (263391) | more than 13 years ago | (#245799)

Here we go again. Its OO therefor it must be better. Wrong. OO is something created for people to understand code-data relationships better, at the machine code level nothing changes. If the data makes more sense in a relational format then leave it that way, don't shoehorn it into an OO format simply because OO is currently flavour of the month. Also OO databases are non generic. Fine if you're only going to use the database for 1 thing but in the real world you may have dozens of apps accessing the same data in different ways. Forcing every application to use the same class models regardless of their needs is a stupid idea. In the real world applications are written in a way to get a job done as fast and efficiently as possible, NOT in a way that would look cool in some ivory tower acedemics OO text book.

Re:If you only found "one" disadvantage, you ... (1)

EllisDees (268037) | more than 13 years ago | (#245804)

Yeah, lets not forget speed, either. It can take a long time to build all of those database objects compared to just looking up the data and pulling it out of the tables...

Re:RDBMS w/ CORBA layer (1)

vulg4r_m0nk (304652) | more than 13 years ago | (#245806)

Well, this is fine, but then you have to build your object-flattening code into your CORBA objects, which is one of the primary reasons to go with an OODBMS in the first place. With an OODBMS you can build CORBA-capable objects that get stored directly in the DB, as long as the CORBA OIDs match or map to the OODB OIDs, and you settle on a policy to correlate activated and deactivated CORBA objects with their representations in the DB.

Only one disadvantage listed ... (2)

vulg4r_m0nk (304652) | more than 13 years ago | (#245807)

But it's a big one. A company I worked for recently employed a RogueWave product to emulate an OODBMS on top of an relational DB, and the result was utter horror. Having to recompile everything as the result of a schema change is a major pain, especially if you have to deal with multiple versions of the codebase. Of course, the situation was worsened in this case because the RW software had to generate all of the mapping code.

I also find that building entity-relation models for relational DBs -- that is, thinking of objects in the form of tables, rows, and columns -- is a very clear way to figure out the problem domain and evaluate different solutions. A successful development process might well include a preliminary stage working with an RDBMS, even if only in working out the conceptual kinks, and then move on to an OODMS.

Finally, a crucial criterion I would employ in which system to go with is the complexity of the data to be stored. The application I worked with was a horrible candidate for an OODBMS because the information itself was simple: names, contact info, and the like, which fits the relational model quite naturally. On the other hand, I'm about to start on a project of my own utilizing highly complex objects, capable of much greater sophistication than in my other example. I will most likely use an OODBMS, for instance db40 [db40.com] .

Too Much Integration (2)

Tricolor Paulista (323547) | more than 13 years ago | (#245810)

Isn't this tying too much of the DB design into the application? And it pretty much precludes reusing a DB unless you have access to the source code, doesn't it?

OODB vs. JDBC (2)

bokmann (323771) | more than 13 years ago | (#245813)

This is a little piece I wrote recently as an internal memo. We use Versant on an internal project, and wanted to justify the use of OODBMS. We want to begin supporting an open-source one, which is where this came in...

---

Premise:

When Java first started appearing in enterprise-wide systems, there were large existing systems containing the enterprise's data. Early on, for Java to have acceptance as a solution to problems in this domain, there had to be a way to access this data... data was not going to be 'recreated' for a new, unproven language.

By far, this data was stored in relational databases, like Oracle and Microsoft's Sql Server. The shortest path to accessing this data in a way that made sense to Java's cross-platform nature was to take an existing specification, ODBC, and create a java-specification based on it. Thus, JDBC was born.

In the years since then, JDBC has matured into a very usable API for accessing relational databases, and a lot of Java developers have had to learn how to use it. Many developers don't even realize it, but there is a mismatch between storing data as an object graph and storing it in a relational database. As a developer, you have to write a lot of code to map between the object world and the relational world. There is a better way.

JDBC is great for accessing existing relational data... It is and should be considered a bridge to legacy systems. If you are starting a new project using Java, there should be a better way. There should be a way to store your data without thinking about it. You should be able to hand your objects to a service that will store them. You should be able to maintain complex relationships between those objects, and you should be able to query that service for objects that match certain criteria. You should not have to muddy up your domain objects with code for storing themselves, and you shouldn't have to extend any objects that a framework provides. You shouldn't have to complicate your build process with 'enhancement' steps, and your objects should not be bytecode modified, so they are still usable in debugging environments.

Does such an object-oriented database exist? In some respects, yes. There are object-oriented databases such as Object Store and Versant. They operate very closely to the ideals listed above. But for most developers, especially those that already know JDBC, their price tags are a large barrier to entry. Until you know the technology, you won't recommend it. You won't recommend the technology until you use it. You are not going to spend $10,000 of your own money to get to know and use a product like this... there are too many other things happening in the Java community anyway.

Conclusion:

These are the reasons object databases have not become popular: There is a high barrier to entry for their use. The databases themselves are expensive. And Java Developers doing database access know JDBC, which is a 'good enough' solution.

In order to overcome this and make object databases take their position in the java community as a preferred way to store data, we need a good, Free, Open Source implementation with all the benefits of transparency of use. Once the database is Free, it must be evangelized by developers. Other developers need to know of it and learn it.

Practicality vs Performance (3)

MatthewNYC (413607) | more than 13 years ago | (#245814)

I just went through this decision-making process with the consultants who are going to build my company's OSS. While OODBMS were an obvious choice to me for performance and ease of programming, my consultants told me that finding Oracle talent was so much easier than finding Versant talent (for example) that I would be wasting time and money using OODBMS. This is especially true of DBAs.

I don't have enough Objects (2)

RalphTWaP (447267) | more than 13 years ago | (#245819)

Of course that's a personal problem

But there's a good reason why it stops my *good* use of an OODB.

If you look well and hard at C++, it's mildly object oriented, you can at least *create* objects, right?

If you look well and hard at Java (god bless it), it's *mostly* object oriented, at least there's a *root* object in the hierarchy, right?... Hmm, what are all those basic components though, is that an integer over there? What kind of object is that again?

Now then, if you managed to find a language whose native types were *all* expressed as objects, where my data were all most naturally expressed as an object (god bless Objective C and Scheme)... well, I'd be much more likely to store my data objectively (come to think of it, I do hate most of my data more than a little).

At any rate, I think the answer is that Object technology is only just coming into its own, and the rigor required of us the programmers to *USE* object orientation to its fullest extent is something that we don't enjoy doing for something as crunchy as DBMS access. Of course, just trying to get the data-creating departments to specify your data in an object oriented fashion might very well bite arse also...
Nietzsche on Diku:
sn; at god ba g
:Backstab >KILLS< god.

Try generating reports on an OO database! (1)

ubeans (449308) | more than 13 years ago | (#245820)

I worked for two years on a project in New York city that was trying to hold makket data using an O2 database. My experience has been that: The accounting people who wanted to generate reports using the tools they were used to (Crystal Reports, Excel, etc.) needed instead to ask the IS department to write programs that would generate flat files (rows and columns) so that the complex, non-tabular OO data could be brought back to tabular data for reporting purposes. Hell it would have been simpler and cheaper to have had the data in an RDBMS in the first place! Another problem was that changes to the schema routinely broke all of our apps. Performance was abysmal, and hiring people who had even heard about the O2 database was impossible. After two years the project was canned. Remember, it's a lot cheaper to make programmers map JDBC ResultSet to objects than it is to have them map OO data back to tabular format for reporting purposes. Your database is worth nothing if it does not support the needs of the business. The ability to be able to perform ad-hoc queries or to load a table in Excel is a must have for most enterprises.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>