Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

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

By Carnage4Life in Technology
Thu May 03, 2001 at 10:01:58 AM EST
Tags: Software (all tags)
Software

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™ 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™

    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™ 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™

    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 become 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™ 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™
    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 seperate 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.

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Poll
What is your favorite database model.
o Relational Model 36%
o Object Oriented Model 14%
o Network Model 2%
o Hierarchical Model 5%
o Flat Files 7%
o I don't do databases 15%
o I don't do code 1%
o austinpowersv("I'm a sexy bitch") 15%

Votes: 76
Results | Other Polls

Related Links
o An Exploration of Object Oriented Database Management Systems
o Dr. Sham Navathe
o ACID properties
o Complex objects
o Object identity
o Encapsulat ion
o Types and Classes
o Class or Type Hierarchies
o Overriding ,overloading and late binding
o Computatio nal completeness
o Extensibil ity
o Persistenc e
o Secondary storage management
o Concurrenc y
o Recovery
o Ad Hoc Query Facility
o ODBMS Facts website
o Object Store
o O2
o Gemstone
o Versant
o Ontos
o DB/Explore r ODBMS
o Poet
o Objectivit y/DB
o EyeDB
o Ozone
o Zope
o FramerD
o XL2
o Also by Carnage4Life


Display: Sort:
Why Aren't You Using An Object Oriented Database Management System? | 74 comments (70 topical, 4 editorial, 0 hidden)
Cost / benefit tradeoff (4.00 / 3) (#4)
by Spacer.human on Thu May 03, 2001 at 05:49:31 AM EST

Editorial: Beautifully written article and a joy to read. Cheers!

And coming along at just the right time. There have been discussions recently in my company about how else we can handle database interaction. We're currently using oracle exclusively but there have been discussions about using an OODBMS recently. I'm wondering how many people out there have experience of using them and what kind of problems people encounter when migrating developers from an RDBMS to OODBMS. From the code examples you've provided it looks much simpler, which is only a good thing on short assed tight deadline projects.

Also (not done nuff research yet) what kind of costs are encountered using an OODBMS. aiui oracle's licensing is pretty corrupt but i'm wondering how it compares with some of the commercial oodbms solutions?

Cheers for the linkage also, plenty of stuff to plough through and throw at those who make the decisions...
Reading Slashdot is like watching the monkeys at the zoo: You already know one of them is going to start throwing its own shit but it is still entertaining. -- l33t j03

might check smalltalk groups (3.00 / 2) (#10)
by hading on Thu May 03, 2001 at 10:12:18 AM EST

Even if you aren't working in Smalltalk, you might find comp.lang.smalltalk (or, indeed, other Smalltalk resources) useful, as lots of Smalltalkers use OODBMS (go figure :-) and there is occasionally discussion of them there. You could probably reap the benefits of others' experience there. Unfortunately I don't really have any serious experience with them myself, so I can't help you directly.

[ Parent ]
Staying put (2.66 / 6) (#5)
by Net_Fish on Thu May 03, 2001 at 06:27:27 AM EST

Interesting article, though I think i will be staying with RDBMS for a bit longer, OODBMS's sound mighty interesting, I think I'm going to have to research them now :)

A very interesting write-up (4.00 / 5) (#7)
by jd on Thu May 03, 2001 at 09:01:21 AM EST

It's maybe a -little- biased - academic papers should really be more neutral, leaving the conclusions until later.

Having said that, I suspect that academic-style writing would go down like a lead balloon in a weblog-style forum.

Ignoring the bias, the write-up is excellent, and the topic is badly in need of more such texts. (OODBMS' have ben around for ages, but I suspect few have seen them, let alone used them.)

One thing I should point out - OODBMS packages -tend- to be skeletal database systems. The database maintainer needs to write actual code, rather than high-level descriptions. This is a serious (but not unavoidable) flaw in those packages.

(For those wanting to take a look at OODBMS stuff, I think there are 5 or 6 "open-ish source" packages over on src.doc.ic.ac.uk. (Since this is a Sunsite mirror, you might find the same packages on nearer Sunsite servers.)

Flat-file databases can be considered 1:1 with flat-file 2-D spreadsheets. Relational databases can be considered as sets of spreadsheets, where any given constructed view is (again) 1:1 with a flat-file 2-D spreadsheet. Object-Oriented databases can be considered as an object heirarchy of spreadsheets, with views as above.

This tells me that it should be possible to manage ANY/ALL styles of database, using the same tools. The only variation would be in the low-level details on how the instructions were actually carried out.

This ALSO tells me that there are as-yet-to-be-tried database models, reflecting N-dimensional maps and complex topologies, rather than constructions of 2-D maps. THESE could prove to be much more interesting, in the end.

Multidimensional Databases (none / 0) (#57)
by admiyo on Fri May 04, 2001 at 02:37:08 PM EST

I know there are a few products out there that focus on the multidimensional aspect of database management. My last company (soon to be two companies ago) Had a product built on top of Arbor (now Hyperion) Essbase to report earnings per share and I know that this was something both MSSQL Server and Oracle were adding to there porducts, although to what degree I don't know. I also read some on Neural Networks (to go off on a bit of a tangent) which are basically massively parallel pattern matchers. The book used vector theory to explain them; specifically the concept of multi dimensionality. Perhaps that is the start of a different access method for Database that will allow for requests with the same sort of requirements as a brain, similarties, incomplete matches etc.

[ Parent ]
DBMS suitability depends on a problem domain (4.28 / 7) (#8)
by alder on Thu May 03, 2001 at 09:14:02 AM EST

Not all tasks in the world can be solved efficiently with object databases, and the same is true for their relational siblings. As it goes each has its strong points in some areas and weak in others.

Example in the article highlights to some extent weaknesses of relational databases when applied to a task of traversing a network of active and complex objects. In some particular domains this is (almost) all you need, and you must do it fast, which relational databases do not handle well.

On the other hand something like analisys (statistical, analitical, etc) of billions of similar records is where relational databases are really good at, and objects are more then overkill for the job - they are nuisances, obstacles, something you do not want to see around.

To sum it up: article is very close to compare apples and ... potatoes, which, though both "round", are in fact parts of different courses of your meal.

Apples vs. Potatoes? (3.40 / 5) (#9)
by Carnage4Life on Thu May 03, 2001 at 09:29:36 AM EST

To sum it up: article is very close to compare apples and ... potatoes, which, though both "round", are in fact parts of different courses of your meal.

Most applications written today that use an RDBMS are not performing statistical analysis on billions of records. In the average case, the benefits of the lack of impedance mismatch and having a single data model are already an advantage besides the fact that an OODBMS would probably outperform an RDBMS.

Secondly I'm sure in my article I mentioned that OO database systems are being used to perform store terabytes of information and perform operations on data at the rate at 35 MB/sec on some systems. So your claim that they aren't good at handling billions of records well is not even well founded.

[ Parent ]
About large recordsets... (4.20 / 5) (#13)
by SpaceHamster on Thu May 03, 2001 at 10:50:28 AM EST

With a query language like SQL, you can create very complex searches where much of the logic gets executed on the server. When you have 100k records and only need to look at 500 of them this saves tremendous amounts of io between the database and your application, and a good RDBMS should be able to optimize it's searching better than a java/c++/etc compiler (I hope). Is there an equivilent mechanism for complex searches in OODBMSs?

Ex.: I want to do processing only on employees that haven't submitted their timecard this week. SQL might look like this: "select empid from employees where not in (select empid from timecards where week='4/30/01')". Then I send a nasty email to every employee in the recordset :P

How would you do this in an OOBDMS? Do you have to iterate through each employee record, ask its timecard member if it has an entry for this week? Can you do this sort of thing directly on the server? If not, is there some magical way OODBMSs optimize this on the client-side? Enlighten me, I'm almost sold :)

[ Parent ]
An OODBMS has a query language (3.60 / 5) (#15)
by Carnage4Life on Thu May 03, 2001 at 11:09:01 AM EST

Ex.: I want to do processing only on employees that haven't submitted their timecard this week. SQL might look like this: "select empid from employees where not in (select empid from timecards where week='4/30/01')". Then I send a nasty email to every employee in the recordset :P

How would you do this in an OOBDMS? How would you do this in an OOBDMS? Do you have to iterate through each employee record, ask its timecard member if it has an entry for this week?

Most OO database systems support querying either the version standardized by the ODMG (which has SQL like syntax) or a homegrown version. Below is what it would look like if you used ObjectStore.

Date endOfWeek = new Date("4/30/2001");
Query qry = new Query(Employee.class, "timeCardSubmissionDate.equals(endOfWeek) == false");


Note that the current standard supports a very SQL-like syntax but since I don't own a copy of the standard I can't give a very good example. Just suffice to say that whichever OODBMS you decide to look at will have some querying facility.

[ Parent ]
Relational model underestimated? (4.50 / 4) (#19)
by dennis on Thu May 03, 2001 at 12:02:08 PM EST

It still looks to me like your query is less flexible. What's elegant and powerful in the relational model is that everything is a table, including the results of your queries. You can query the results of your queries, join the results of two queries and filter that, then find every item in another table that's not your results...whatever.

Can an object database do this? In the examples so far it looks like the programmers have to provide for everything you're going to do. In your example above:

new Query(Employee.class, "timeCardSubmissionDate.equals(endOfWeek) == false")

all you're doing is checking one field against a predefined value; where the previous poster's example was querying a subquery, which could have been anything.

[ Parent ]

Thinking Relationally Instead of Object Oriented (3.50 / 6) (#24)
by Carnage4Life on Thu May 03, 2001 at 12:43:00 PM EST

It still looks to me like your query is less flexible. What's elegant and powerful in the relational model is that everything is a table, including the results of your queries. You can query the results of your queries, join the results of two queries and filter that, then find every item in another table that's not your results...whatever.

And most of these are all a convoluted mechanism to get around the fact that there is no easy way to express relationships. If I had designed that application in an OO manner instead of simply trying to use queries in a relational style model then this is what I would have done.

OSHashMap timetables = (HashMap) db.getRoot("SubmissionTimes");
Query q = new Query(MapEntry.class, "value.date() < endOfWeek.date()");
Set tardyEmployees = q.query(timetables);

The above code assumes that you have a hastable of employee names and the last time they submitted a timesheet. So all you do is query that hashtable and get back a Set containing all the employees whose last submission does not match the endOfTheWeek value which I assumed is defined outside the code snippet.

all you're doing is checking one field against a predefined value; where the previous poster's example was querying a subquery, which could have been anything.

The value does not have to be predefined. I did that because I don't think there is a mapping in OQL for a 'MM/DD/YYYY' to be implicitly converted to a Java Date object. The value was a variable that can change as is needed.

Secondly the main reason people perform queries of subqueries is because the relational model makes dealing with relationships a convoluted task.

Finally, you are correct that queries are limited in that they can only be run on a single class whereas SQL queries can be run on multiple tables.

[ Parent ]
Multipath Relationship Support... (4.00 / 3) (#29)
by aziegler on Thu May 03, 2001 at 02:40:17 PM EST

It still looks to me like your query is less flexible. What's elegant and powerful in the relational model is that everything is a table, including the results of your queries. You can query the results of your queries, join the results of two queries and filter that, then find every item in another table that's not your results...whatever.

And most of these are all a convoluted mechanism to get around the fact that there is no easy way to express relationships.

Not really. It allows you to quickly and easily apply multi-level filters. OODBs -- like most OO systems -- have a hard time dealing with multipath relationships. By this, I mean a situation where certain information is useful on its own (or nearly enough), or that it can legitimately be considered a child of two different tables. In an OO system, this has to be stored redundantly, or the relationship has to be stored externally (just like in an RDBMS).

If I have a system that has an ACCOUNT object (table) and a PACKAGE object (table), the child of the two would be the ACCOUNT_PACKAGE object (table). In some ways, this could be stored as a child of the ACCOUNT object -- but if ACCOUNT_PACKAGE needs to be examined independently of the ACCOUNT object (for *whatever* reason -- and I work in a system where the business reasons essentially require it), then an ODBMS is inherently useless. (For example, I may need to find out who owns a copy of the package -- without traversing each and every bloody account.)

Without the ability to support multipath relationships -- I can't even THINK about using an OODBM for any serious purpose.

-a

[ Parent ]

Still don't buy it (4.40 / 5) (#30)
by dennis on Thu May 03, 2001 at 02:41:08 PM EST

queries are limited in that they can only be run on a single class

In this case it appears to me that the object database is the one that makes it hard to express relationships. In a relational db it's quite easy, just match column values.

I work on a system with about a hundred tables. We query them in all sorts of strange ways, relating tables in ways we hadn't thought of when we designed them, and it's quite easy. We are constantly taking on new clients with new business rules, and extending the system is seldom a problem. There's only one programmer besides me working on this so we don't have resources for a lot of re-engineering, and we learned the business as we went. Flexibility in querying is crucial for us.

To match the flexibility of SQL, you would have to be able to query multiple kinds of objects at once, and get a set of objects combining attributes from both, and be able to query them. An object system is great when all your relationships are hierarchical, but the limitations of hierarchical relationships were what drove the adoption of relational dbs in the first place.

[ Parent ]

Apples and potatoes have different niches (3.00 / 3) (#21)
by alder on Thu May 03, 2001 at 12:21:22 PM EST

having a single data model are already an advantage besides the fact that an OODBMS would probably outperform an RDBMS

You are absolutely right about the benefits of a single paradigm, as I would rather call it, in OODBMSes vs. relational world where you have to take a multitute of approaches: declarative SQL, imperative, traditionally, server side language - PL/SQL, Transact SQL, 4GL, etc, and on top of this object-oriented client. There could not be any arguments about this - common development paradigm is one of the key features of OODBs that makes them so attractive.

Another substantial benefit of using OODBs is their special ability to handle static relationships between objects. This is another key feature - they perform node traversal so fast that no relational database can beat them. Here you are probably right too - a lot of tasks that involve any form of persistent storage spend most of thir time in restoring static relationships, so why not to use a tool that is very good at it.

Having said that, I must add that there are other tasks. Consider something like stock (or maybe better example - options) market analysis, where your data are all the same, you just have to run very fast through the market history accumulated over time. Or just Web server log report generation... There are no significant static relationships there, so OODB cannot bring any advantages.

What I'm trying to prove (not very good probably :-) that there are different tools for different tasks and they are good in there respective areas. You gain a lot if you select a proper tool for the job.

Regarding those performance numbers. You remember a saying about lies, statistics and benchmarks, right? :-) On a serious note, 35MB/sec is a contribution of a system mostly, not OODB, and probably especially suitable benchmarking task (for OODB to have its piece of a pie). You do not seriously believe that same number is not achievable on the same hardware by RDBMS that crunches rows and rows of data to make a report, don't you?

Please, do not misunderstood me, I'm not against OODBMSes, no that sounds terrible, - I would love to work with them. It's just that not every project that needs database will benefit from OO database, even if most do.

[ Parent ]

Standards and vendor lock-in (3.80 / 5) (#11)
by Pseudonym on Thu May 03, 2001 at 10:29:50 AM EST

SQL is an ANSI standard. For connecting to the RDBMS, there's ODBC, Java's JDBC, Perl DBI and so on. These all help prevent vendor lock-in. If I want to dump one DBMS and use another instead, so long as my SQL is sufficiently portable, I can just change a one or two places and I'm done.

When I evaluated OODBMS systems some time ago, I found that they all fell down on this point. There was no standard query language, no standard language binding, language independence was extremely painful and so on.

I have no doubt that OODBMSes have much promise. In particular, the real-world rarely comes in tables and rows, so modelling data is very nice. But does the current state of the art of OO databases let me change database vendors easily? If not, I'm not switching.



sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
ODMG 3.0: The Standard Does Exist (3.33 / 3) (#12)
by Carnage4Life on Thu May 03, 2001 at 10:38:43 AM EST

When I evaluated OODBMS systems some time ago, I found that they all fell down on this point. There was no standard query language, no standard language binding, language independence was extremely painful and so on.

There currently exists ODMG 3.0 which standardizes language bindings, an Object Query Language, the Data Model and file format so objects can be exported between DBs. You can even order the standard for $39.95.



[ Parent ]
Where's the support, though? (4.00 / 3) (#14)
by Pseudonym on Thu May 03, 2001 at 10:52:43 AM EST

I saw that. I also saw how bad the support is for the standard.

It's also a shame that they don't list the open source OODMBS systems that you mention in the list of how good they comply with the standards. Could you possibly give us a precis? Of the open source OODBMS systems you mentioned, how many comply with a sufficiently large subset of the ODMG standards to be useful?



sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
[ Parent ]
My €0.02 (4.22 / 9) (#16)
by decaf_dude on Thu May 03, 2001 at 11:15:54 AM EST

Huh!

Great article, well thought out, clear goal, driving the point of view well.

But...

Disclaimer: I am the only son of an IBM veteran of over 20 years and have been taught from the very early age that referential integrity is good!

I don't see OODBMS replacing RDBMS anytime soon (read: next 5 years), although I could be forced to eat my words. RDBMS have been around for over 30 years, in businesses worldwide. You don't need anyone to tell you that RDBMS do work and they work well. Over the past 30-odd years, programmers (and system architects) have learned to think about data items and structures in terms of their relationships and, as any CS graduate will tell you, it feels right. Sorry, you'll have to pry my primary keys from my dead cold fingers ;-)

I've used Pascal (yeah, I know...), C (I hear there are people who actually use it voluntarily), C++ (I started a hobby of sticking toothpicks deep under my fingernails right about the same time...), VB (hey, it was either that or flipping burgers in Macky-D's)... Lately, I use Java (J2EE) almost exclusively. I will agree that data type conversion was once upon a time a major issue, but nowadays Type 4 JDBC drivers make that very transparent. Of course, it is not a panacea, you do hit a snag from time to time. Mostly, though, it works fine, you learn ways around.

Now, to convince the businesses... no, make that programmers... to switch the data storage paradigm is really hard, if not impossible. C'mon, just ask yourself this: "Of all Java code you've seen, how much of it is real, clean OO?". With C++, situation is even worse. Heck, most of the C++ code I've seen could easily be compiled with a standard C compiler, perhaps with a few minor modifications. In my experience, even those who write Java, which BTW is very anal about OO by design, don't really think in object terms. If the main() is more than 50 lines long for a complex program, that ain't no OO!

Personally, I have no problem with RDBMS and haven't honestly given much thought to OODBMS. Maybe your article will have provoked me enough to try to play with one. I love PostgreSQL (that's what I use when I make decisions), and it is claimed to be ORDBMS - Object Relational DBMS. I guess I'll have to investigate that now :)

When do I think OODBMS will make their way into the mainstream? When IBM, Oracle, Sybase, Informix, Microsoft, et al. start shipping it as standard.

Oh, and by the way, I'd strike out that Iridium reference out - you don't want to talk about success and Iridium in one sentence :)

Another thing: I believe the technical term for the famous Employee/Manager relationship you refer to is involuted relationship.


--
http://slashdot.org/comments.pl?sid=89158&cid=7713039


Postgres -- the O (3.75 / 4) (#20)
by rbt on Thu May 03, 2001 at 12:17:29 PM EST

The O in postgres comes from a few things like INHERITANCE.

CREATE TABLE employee ( name varchar(20));

CREATE TABLE manager ( title varchar(20)) INHERITS (employee);

Insert into manager, and you can fiddle with it in employee. Works good for lots of things -- but generally only makes the DBA's life easier -- not those using the system.

[ Parent ]
PostgreSQL == ORDBMS (4.00 / 2) (#34)
by chewie on Thu May 03, 2001 at 04:21:22 PM EST

IIRC, that is. PostgreSQL people often refer to their database as an Object Relational Database Management System. It's not true OODBMS or RDBMS. It's more of a RDBMS with OODBMS-like qualities. Check out the docs at: http://www.postgresql.org
assert(expired(knowledge)); /* core dump */
[ Parent ]
um, yeah (none / 0) (#74)
by klamath on Wed Jun 05, 2002 at 01:50:39 AM EST

No one said that PostgreSQL was an OODBMS -- the three terms "OODBMS", "RDBMS", and "ORDBMS" all refer to distinct types of database systems. PostgreSQL is not, nor does it claim to be, a OODBMS.

[ Parent ]
Postgres -- the O (none / 0) (#65)
by Ehud on Sun May 06, 2001 at 08:21:25 AM EST

Inheritance in PostgreSQL is nice, but it lacks some things which would make it more useful. You cannot have a foreign key reference a table and all its children, for example. That is, not easily, you can do it with home-made triggers.

There are probably good reasons for this, but it would still be nice to have.



[ Parent ]
Java? (3.00 / 5) (#22)
by Knight on Thu May 03, 2001 at 12:22:26 PM EST

Don't get me wrong, Java's great, but I guess I don't understand why some people so strongly lock onto 4GL languages. To me, there's just no interest in programming if I'm not directly manipulating memory. Granted, C and C++ take care of some of that for you, but you can take it over if you like. The ability of C(++) to allow me to do things that probably aren't normal (like cast a char * to a DWORD * if I want to) has saved my bacon on many occasion, and languages like VB and Perl, which "take care" of memory and types for me give me hell. Anyone ever heard of an 'SV'? Perhaps I'm just a masochist, but I'll stick to C/C++ with interspersed assembler when I want serious speed.

[ Parent ]
Another of the true faith! (3.33 / 3) (#35)
by deefer on Thu May 03, 2001 at 04:28:01 PM EST

I like Java, too.

The only thing I dislike about it is the lack of malloc(). Sorry, guys, but new(type) just doesn't give me the warm fuzzies. And you can do some really neat, optimisable tricks like casting a void pointer to be a record type then bumping the pointer along...

Sounds like you're an old school programmer like myself. I'm not averse to using Java or other 4GL languages when the problem lends itself to it but these days the colleges are turning out graduates who don't even know that the processor has stack registers... <shakes head in disbelief>. If you're going to use a 4GL language, at least have an understanding of what is going on under the hood cos otherwise you're screwed when the compiler starts making some incorrect decisions on your behalf...


Strong data typing is for weak minds.

[ Parent ]

Need to Know (3.00 / 2) (#56)
by leviathan on Fri May 04, 2001 at 01:56:57 PM EST

I don't mean to start a language flamewar here or anything, but...oh well, if it's gonna, it's gonna.

Most of the time, for mere mortals, abstraction is a good thing. Personally, I prefer writing in either assembler (when it's called for), Java or Python. Unless the job specifically calls for more speed than a high level language can deliver, I don't really need to go any lower.

Sure, I occasionally feel a pang of guilt that the system I've just built could be running 5x faster and 3x smaller, but then I just remember that I would then have taken 5x as long to write it and I'd be tied in to one platform more tightly. Just look at those UML diagrams - don't they just look juicy?

High level stuff feels good and low level stuff feels good (from a CS point of view). C always feels strange to me; it's like programming assembler with boxing gloves on. Sure, it gives me easier control over my functions, but if I need that, couldn't it be better designed in objects and classes?

--
I wish everyone was peaceful. Then I could take over the planet with a butter knife.
- Dogbert
[ Parent ]

I don't care about memory. (4.00 / 1) (#72)
by Phil Gregory on Mon May 21, 2001 at 11:56:13 AM EST

I program, and I do mostly application-level programming (as opposed to system-level programming). I like not having to worry about where every little bit of memory is going. When doing stuff in C, I often have to micromanage my memory allocation ("To whom does this chunk of memory belong?" "I need a string here. Which procedure allocated the memory and which should free it?"). In the languages I use regularly (Delphi, Java, and Perl (and sometimes Common Lisp when I feel like playing)), my memory concerns are more abstract ("This object has this lifetime, so it needs to be created here and freed there.") and less annoying than in C.

I can certainly see the applications of C in many contexts, but, for the purposes to which I program, it's not all that great for me.



--Phil (The more time I spend away from C, the ickier it is when I go back.)
355/113 -- Not the famous irrational number PI, but an incredible simulation!
[ Parent ]
Oracle already walks this path... (3.00 / 2) (#27)
by aralin on Thu May 03, 2001 at 02:32:27 PM EST

Well, you might want to know that in less than 2 months should be out Oracle 9i DBMS which has now strong OO support and I'd guess that Oracle 10i might be working in either Relational or OO mode.

[ Parent ]
Iridium refrence? (1.66 / 3) (#32)
by delmoi on Thu May 03, 2001 at 04:03:10 PM EST

Oh, and by the way, I'd strike out that Iridium reference out - you don't want to talk about success and Iridium in one sentence :)

Um... you didn't....
--
"'argumentation' is not a word, idiot." -- thelizman
[ Parent ]
No Primary Keys? (3.20 / 5) (#17)
by moscow on Thu May 03, 2001 at 11:23:31 AM EST

I agree that a primary key in an RDBMS provides uniqueness in a row, but the main practical use of primary keys is usually to speed the search process by providing an index. It is perfectly possible to have a table without any key at all, even if this isn't good (normal) form.

However, mostly these kinds of tables will have an id column added to provide an index and a unique value. I don't see how this is any different to providing an OID for each object in the database. In fact, these artificial keys are often used as for child tables and foreign keys in any case. The most likely operation is of the sort where you map a flower to its garden bed and all of the flowers returned may be blue lupins, but each is a separate table row.
e.g.

select flower_id from flowers where garden_bed = 'SW'

This doesn't seem that different (conceptually) to having a garden_bed object where the SW instance has pointers to the OIDs of the individual flowers.

Of course, going back to practicalities, it may be vastly quicker to have a list of OIDs which are held with the SW instance rather than searching any index. However, surely such an approach is very brittle if there is any other way of updating the flowers. If some of the OIDs of the SW bed are incorrect, database corruption is probably close behind.

Primary Keys and Indexes are Different Concepts (5.00 / 1) (#31)
by Carnage4Life on Thu May 03, 2001 at 03:59:35 PM EST

I agree that a primary key in an RDBMS provides uniqueness in a row, but the main practical use of primary keys is usually to speed the search process by providing an index. It is perfectly possible to have a table without any key at all, even if this isn't good (normal) form.

No. Indexes are seperate from primary keys. An index is a column in a table you want to the DB to optimize queries for by putting the value in a B+ tree or similar structure. Both relational databases and object oriented databases have indexing functionality. Primary keys and OIDs on the other hand are used to uniquely identify entities in the DB.

Secondly I'm not sure I've ever seen an RDBMS that would allow you to create a table without a primary key unless it did it implicitly.

[ Parent ]
Tables without PKs... (none / 0) (#39)
by aziegler on Thu May 03, 2001 at 05:58:46 PM EST

I know that Oracle allows it, but you can't use the table as the source of a foreign key relationship without it, and it's dumb not to have a primary key except in the oddest of cases anyway...

[ Parent ]
DB2 allows it... (none / 0) (#66)
by 42 on Mon May 07, 2001 at 01:59:48 AM EST

...and so does (did) INGRES. And given that the other reply to your post said Oracle allows the creation of tables without a primary key - I would hazard that the situation is the opposite of what you said - I am not sure that there is any "real" database that doesnt allow the creation of tables without a primary key. Indexes are separate from primary keys only at a conceptual level. When you get down to implementation level details, the original poster was right - primary keys are implemented in terms of indexes.

[ Parent ]

Not Ready Yet, but really interesting (2.60 / 5) (#18)
by gauntlet on Thu May 03, 2001 at 11:40:59 AM EST

I've taken a quick glance at OODBMS in the past. I have come across at least 2 circumstances in design of various database where the ability to create inherited types would have been extremely useful.

As a basic idea, it would eliminate the need to create a "LastUpdated" column in every single table, and every single update statement.

However, I deal with reporting every day. I will wager that it is not only when the query language or interfaces are standardized that OODBMS will gain acceptance, but also when there are mature software packages out there to help newbies grab useful information from the database.

That would be an interesting interface design challenge. How do you make multiple inheritance visually obvious to your mom? :)

"It is difficult to catch a black cat in a dark room. Especially if there is no cat there." - Confucius

Mom would not use OODB (3.00 / 2) (#23)
by alder on Thu May 03, 2001 at 12:42:01 PM EST

The biggest advantage of OO databases is the ability to store complex structures (objects) in their "natural" form and later take them out ready to run in ... a complex OO system. The key point here is that there is a system of classes, objects and their relationships, which is inherently difficult to design if you did not train yourself to think in those terms. There is an upside though, if you used to design you systems as OO, OODB would be the most natural persistent storage for what you are designing.

Relational databases have an inherent advantage to be big spreadsheets for small projects, so even your mom can easily understand what is going on, and later, when system evolves, will be able to grow with it - learn about realtionships, constraints, triggers, procedural language of data manipulation, etc. With OO it cannot work this way - you have to teach her to think in terms of objects, and there is nothing in her direct experience that helps...

[ Parent ]

Does that mean (3.00 / 1) (#25)
by gauntlet on Thu May 03, 2001 at 12:58:29 PM EST

that you expect the only people that will really be able to take advantage of reporting tools that attach to OODBMS will be those that have a prior training in OO? Or do you think that the software will simply try to translate theOO structure to spreadsheet form for "Mom".

BTW, when refering to "Mom", I'm referring to people that use database reporting software right now with nothing but a minimal understanding of database structure.

"It is difficult to catch a black cat in a dark room. Especially if there is no cat there." - Confucius
[ Parent ]

Depends on tools (3.00 / 1) (#28)
by alder on Thu May 03, 2001 at 02:34:43 PM EST

Well, some tools will be there to help generate reports and do all other useful things. And an everage person will be able to use it. Though a "Mom" can design her own spreadsheet, and make it work for her, but I doubt she'll be able to design OO database.

Again, what I'm trying to say here is that OODBMS is not a new panacea for data storage and manipulation. Some people are happy with their spreadsheets, some need relational databases, some require OODB. Currently we use RDBMSes to store objects (no, not everyone, but it's common enough). What I dislike is a vision of everyone moving to objects just because they work. They do work, but they work the best in specific areas. The latter is true for spreadsheets as well :-)

[ Parent ]

ZODB anyone (3.00 / 4) (#26)
by costas on Thu May 03, 2001 at 01:09:11 PM EST

Liked the article, and I'd like to ask a related question: has anybody played with ZODB, the Zope Object Database, basically Zope's storage layer that's available as a separate project (on SourceForge)?

ZODB can store Python objects transparently and it looks like a really interesting toy to play with --although it's not a toy by any means, since it powers Zope...


memigo is a news weblog run by a robot. It ranks and recommends stories.
ZODB experience (none / 0) (#59)
by akuchling on Fri May 04, 2001 at 05:51:30 PM EST

We use it at work, which was the reason I made a separate packaging of it. Our site actually went into production a few weeks ago, and so far the experience has been pretty good; I'm quite pleased with the flexibility that using the ZODB has given us. The system is now much more maintainable because everything is in our Python code, not scattered across code and DB tables and stored procedures. I've started thinking about writing an article or paper about our experience.

[ Parent ]
Any performance specs? (none / 0) (#61)
by costas on Sat May 05, 2001 at 04:10:33 AM EST

or at least a rough idea? Can ZODB handle thousands, hundreds of thousands or millions of entries? how well compared to a SQL database? Note, that I am asking for an RDBMS comparison only as a rough benchmark, I still want to use an OODB.

memigo is a news weblog run by a robot. It ranks and recommends stories.
[ Parent ]
Any performance specs? (none / 0) (#62)
by costas on Sat May 05, 2001 at 04:10:57 AM EST

or at least a rough idea? Can ZODB handle thousands, hundreds of thousands or millions of entries? how well compared to a SQL database?

Note, that I am asking for an RDBMS comparison only as a rough benchmark, I still want to use an OODB.

memigo is a news weblog run by a robot. It ranks and recommends stories.
[ Parent ]
The reason *I'm* not using one... (4.00 / 5) (#33)
by rabbit on Thu May 03, 2001 at 04:15:35 PM EST

..is that they're a pain in the ass. They sound absolutely fantastic from a theoretical standpoint. You get to organize data in a much tighter fashion. A someone's address and phone number for example in a payroll database all go into just one "object". When I first started reading about OO databases, I became quite excited (yeah, so I'm a nerd) about the possibility of clean, compact, well organized data, until I actually tried to use it....

The problem I found is that getting data into and out of objects, and doing quick queries against these objects quickly becomes a royal headache.

You think joins are bad: wait until you try doing a join on two (or more) fields that are deep inside of different objects. Major pain in the ass. And unless the object model of your "client" software (in my case, say PHP) exactly matches the object model of your DB server software, you STILL have to do all that funky translation crap to move the data between application and database.

Until OO languages and OO Databases can talk in a reasonable manner and OO Database are mature enough that you're not using heinously kludgy syntax to get at their objects, I'll be sticking to RDBMSs thank you very much.

The other thing to consider, and I do not have the numbers to back this up, it's just a suspicion... based on the kludgy nature of say, Oracle's object model, I would suspect that Object queries are probably slower. They've been doing RDBMS for years and years, and they're quite good at it, and they're quite fast, even if Oracle is something of an unwieldy beasty(not to mention the spead of say, MySQL). Based on my experience with OO DBs, they simply haven't been doing it long enough to do it well. At the very least, I've found that dev times go through the roof, and I'm not willing to *increase* dev time just to use a new method that is "theorectically" better, but in practice, probably a whole lot slower.

We're still at a point (and probably will be for a few years), where the "older", RDBMS technology is so well refined that it's going to significantly out perform the "new" ODBMS technology. Sort of like back in the day, when cars first came into being - for most people it just *made more sense* to keep the horses - because they were faster and cheaper.

-- I have desires that are not in accord with the status quo.
XML! (none / 0) (#54)
by fluffy grue on Fri May 04, 2001 at 01:19:49 PM EST

<sarcasm>XML will solve all that! It'll cure cancer, too!</sarcasm>
--
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]
[ Parent ]

The JADE experience (4.28 / 7) (#36)
by Moron Mk2 on Thu May 03, 2001 at 05:03:49 PM EST

I just finished working on "phase 1" of a project, and we're not deep into phase 2 (fixing all the things that we broke in phase 1).

Basically, the project is a website that takes all the information for conference registration. It sounds pretty simple because, well, it is pretty simple. We needed to take people's information, store it, print out nametags, recipts, etc, and be able to do all this over the internet or onsite. The old system was mostly a hack using Access as the core data-thingie (I refuse to call Access a database under any circumstances... it'd be like calling my Palm 5000 a mainframe).

The problem with this project is that, in addition to the usual problems with these projects (ie they must be reliable and secure... but hey, what doesn't?), the conference in question is a conference of Computer Science educators, so if I do something wrong, I'm going to hear about it. We started using an OODBMS and integrated environment called JADE. It's very slick, but we came up with some issues and some things that probably could have been done better.

First, the good: the Jade Database is pretty much transparent. That is, you don't even realize that there IS a database. Objects get created, they go somewhere, and they come back out when you need them. I'm not sure if this is good or bad, but it sure as heck made development go faster when we know that the objects that we make will hang around forever. The downside: If you want to save your classes, you have to go through this complicated back-up procedure. The day before the system was supposed to go up, someone (And I'm not naming any names, let's just say he's a frequent K5 lurker who's writing his first post right now) accidentally removed a signifigant portion of the forms required for administering and editing the attendees and their "stuff" - nametags, tickets, and the like. The downside? That person sat hunched over Jade for about 24 straight hours entering it all back in from memory. The upside? Jade made it pretty easy to put it all back in, and it went in alot faster the second time (about 6 weeks of development were redone in about 12 hours of actual coding, intertwined with about 12 hours of watching "Cowboy Bebop"). Another bonus is that you can change whatever you want, and the system never goes down. We redesigned major portions of the administrator system long after the system went up, and it never went down for the updates - the system IS the development environment, and as you add things, compile them, and link them up, they just become available. Downtime is nearly unheard of.

In addition, in Jade, objects do whatever you want them to. So rather than have a webform which feeds into some object that stores, say, data about a conference workshop, the form IS the object - the things that make the object unique (ie the workshop's actual data) are stored for you someplace, while the other stuff is not. We ended up with a database of around 1200 people, 30 workshops, and other various and sundry "stuff" that fit on a single floppy disk when we were backing it up and moving it around

Jade is also a seperate programming language, similar in some ways to pretty much every other non-lisp language I've ever used. Some part of the total system we developed reminds me of pretty much every language I've ever used. I won't bore you with a code snippet because there's no way I can come up with a chunk of code that can show of anything signifigant on the spot... but there's plenty at www.jade.co.nz

Now the bad parts... Jade only runs (as a web server plugin) on NT, and in general on windows platforms. We wanted the web module to be secure. That's a problem. There's rumours of a Solaris port, but I'll believe it when I see it. So, we ended up with a Perl frontend (That may become JSP soon if that solaris port doesn't materialize) that wrote things into an existing Oracle database that technically belongs to someone else, and then oracle and Jade sharing things though a file in a safe environment. This was a fantastic pain in the ass, and we ended up with a few of people who got their registration confirmed but never ended up in the Jade database.

Second, the form designer module is nice for developing internal tools for administration, but for web design, it is very weak... not alot of control is given, and don't even THINK about editing the HTML by hand.

Lastly, the language can be a bit cumbersome at times. I think that too much work went into making sure the language was "user friendly", and the result is a language that is easy to use, and which makes manipulating objects in the database simple, but which is more suited to an introductory-level CS course than serious database system development.

On a nit-picky level, the language does have some nice things... first of all, any method without arguments doesn't need parens... so you can just moron.beStupid instead of moron.beStupid(). Yes, it's minor, and it gets confusing... but it was cool for about 5 minutes. I'd have to say that, on the whole, the most annoying thing about the language is the 1-indexed arrays. I'd like to meet the man who made that decision and hand him a dead wombat.

On the whole, the system is fairly easy to learn and use, and, while probably not great for huge, heavily used systems, it was pretty sharp for what we did, excepting the web problems. A little more time to mature and I think you'll see Jade show up in a few more places.

MM2


Why am I not using OODBMS? (3.50 / 4) (#37)
by khallow on Thu May 03, 2001 at 05:30:13 PM EST

<sarcasm> Because I don't need to? </sarcasm>

There's a vast number of database applications that simply don't need to use OODBMS. I recall a friend who was using Berkeley DB (a hash look-up data base) for his storage. A group of us encouraged him to switch to an SQL database. It turned out to be a so-so idea (aside from appealing to business uses). The data base was small and very simple. The performance hit was more important than the data integrity (or other nifty features) that comes with SQL (Postgres in this case). An OO database would be overkill and even more inefficient.

We do seem to be moving into a world where funky objects need to be stored efficiently, but I wonder if there are better ways to store them than with the current OODBMS ideas.

An alternative would be to use a more natural OO language like prolog, lisp/scheme, smalltalk, or your-favorite-OO-language-here in some sort of persistent interpreter scheme. Prolog in particular has a nice operating model that should extend to a database. Suppose I have a scalable (to multiple machines), persistent prolog intepreter that can take input from sockets? It would be much more powerful as a database than what we currently have. Only little itty-bitty problem is that we have just one (sockets) out of three - i.e., no persistence and no scalability (at least to my knowledge). Err, no real security either. OTOH, I put my data as rules into the interpreter and --presto!-- get the ability to do some serious computations that no mere database can touch.

Finally, just how usable will one of these be? I can envision an OODBMS that is much easier to use than a RDBMS, but once you start tossing in all the standards' abominations (e.g., UML), then it could become a complicated beast. A data entry clerk won't handle complexity. Someone will have to protect the lusers. Oh well, I could do with a raise. :)

The point is that I know that OODBMS as an idea is going to dominate eventually , but I'm not impressed with the current direction.


Stating the obvious since 1969.

Carnage4Life, nice paper (5.00 / 1) (#38)
by khallow on Thu May 03, 2001 at 05:36:11 PM EST

Sorry, I hadn't really read the paper before I foamed at the mouth. Still stand by what I said, but the paper does a good job of pointing out the benefits of OODBMS over RDBMS!


Stating the obvious since 1969.
[ Parent ]

Why not to use it: bad experience? (5.00 / 4) (#40)
by tjansen on Thu May 03, 2001 at 07:22:55 PM EST

I was part of a three year project that tried to write a piece of software using one of the commercial object-oriented databases from your list. It failed miserably. There are a number of reasons why I would think twice before doing this again as the database was one of the reasons for this. The lessons I learned about programming and OODBMs (and the one we used in particular):
  • Do not bet your company on a project that depends on a commercial piece of software from a single vendor. The problem with OODBMS is that, unlike RDBMS, it is really hard to switch databases in the middle of the project. So if the database has a problem, your company has a problem. Our OODBMS of choice unfortunately crashed in certain situations on NT and Solaris. We spent weeks to trying to fix this, and the support staff from the database vendor was not able to help us at all. A workaround on NT was relatively simple, the problems disappeared when we reduced the number of listening threads in our product's (integrated) webserver. On Solaris the db coredumped each time the process got a signal. When you have a webserver and the client aborts a download (by pressing the STOP button) you get a SIGPIPE and bang, your server crashed. Unfortunately it is hard to think of something like this when you work in Java. When we used a JNI extension that turned off SIGPIPE the app server worked as expected. We reported the bug to the db vendor, several times. The bug was 100% reproducible (init database, send signal, crash) and it took them over a year to fix it...
  • Building your software in an object-oriented fashion, with inheritance and so on, is fatal when you discover later that you need to search through your data. While oo database can execute queries you need to have a data model similar to that of a relational or dbm-style database. However, if you have a complex structure with many small objects searching will get really complicated, if possible at all. In our case it turned out that it was not possible to use the build-in query features, we had to write them ourselves.
  • Once you have a data model it is very hard to change it. To access the data in the OODBMS you need to have exactly the classes that created it. You cannot write a small script, maybe even in a different language, that just reads the data and writes it in a different format into a new database. For small changes (like adding a member to a class) some dbs have a feature called schema evolution. We made the mistake to trust our db in that it was easy to do minor changes later. Well, unfortunately the db got surpringly unstable once we started to change the schema. The comment of the vendor's support guy was just that he recommends to use the schema evolution only in simple cases, not in real-world uses. Let me tell you that customers are not very happy to hear something like "sorry, but we cannot migrate your data to the new version of our product. Our db does not support this."...
IMHO the "impedance-match" is not worth the trouble. It is a GOOD thing to separate your data model in the db from the the implementation, it can save you a lot of trouble later.

Needs clarification (4.00 / 6) (#41)
by KWillets on Thu May 03, 2001 at 07:40:14 PM EST

I'm afraid a lot of this paper just touches on topics that need a lot of clarification or supporting evidence to be convincing.

If I could narrow it down to just a few points (I'm trying), I would say that "RDBMS" is almost as broad a catch-all as "OODBMS", it just suffers from the fact that there are only a few well-known "RDBMS" products in real world use.

The core relational model is an abstract structure which admits a wide range of physical implementations, so assertions like "an OODBMS is better suited to handling complex,interrelated data than an RDBMS" tend to fall back to finger-pointing at Oracle's file-and-block-based addressing scheme, or the performance of ISAM files, or joins, or any number of physical pecularities of one implementation or another, instead of the merits of one model versus another.

All database implementations are limiting in one way or another. Every implementation has to manage tradeoffs in access speed vs. locking, transaction management, reliability, parallelism, cross-platform support, and any number of factors which make "one best solution" impossible.

However, there's nothing in the relational model which makes it less amenable to one physical architecture than another. Virtually any addressing scheme, locking algorithm, data storage format, or indexing method can and does work as well in an RDBMS as in an OODB. You can buy RDBMS products which address with pointers (TimesTen) and do pointer swizzling (UniSQL) the same way OODB's do. You can buy RDBMS products which use object id's instead of primary keys (UniSQL, Oracle, DB2) (Oracle recently re-christened its ancient row id's as "object id's" to drive home the point). The fact that many of these products have only a niche market compared to the big traditional RDBMS implementers does not suggest that similar OODB implementations will prevail.

The "impedance mismatch" claimed for RDBMS's is paralleled in just about every other cross-platform tool I can think of. In every case, the task is the same: to map objects from one whatever-endian, different-character-set, possibly-FORTRAN environment to another, without losing or distorting anything, while asking the programmer as few questions as possible. In most cases the client must still choose, eg, whether to map a BCD to a float or an int, and there's simply no way around the problem. Granted, it can be easy to write in a language which has the same object format as the DB, but that's not saying much for portability.

I hope I'm not coming off as too much of a relational bigot. I do have more real-world experience with "pure" relational DB's, but my point is that OO and relational are so similar on the logical level that there's not much to argue over. But below the logical level, below the physical level, there's the marketing level, and that's where most of the arguments come from.

The theoretical is not divorced from the practical (none / 0) (#43)
by Carnage4Life on Thu May 03, 2001 at 10:37:19 PM EST

The core relational model is an abstract structure which admits a wide range of physical implementations, so assertions like "an OODBMS is better suited to handling complex,interrelated data than an RDBMS" tend to fall back to finger-pointing at Oracle's file-and-block-based addressing scheme, or the performance of ISAM files, or joins, or any number of physical pecularities of one implementation or another, instead of the merits of one model versus another.

Theoretical models have real world implications. The concept of a tuple (or table) in a relational implies that it should be in a contiguous block of memory. Also queries that involve relationships will require a join which means those contiguous blocks of memory need to be merged somehow, at least logically. The OID concept in OODBMS parlance on the other hand implies that all OIDs can refer to which other specific OIDs they refer to, so that doing a relationship based lookup is more a graph or tree style search than logically merging two contigouos blocks of memory then doing a linear search.

The "impedance mismatch" claimed for RDBMS's is paralleled in just about every other cross-platform tool I can think of. In every case, the task is the same: to map objects from one whatever-endian, different-character-set, possibly-FORTRAN environment to another, without losing or distorting anything, while asking the programmer as few questions as possible. In most cases the client must still choose, eg, whether to map a BCD to a float or an int, and there's simply no way around the problem. Granted, it can be easy to write in a language which has the same object format as the DB, but that's not saying much for portability.

You have misunderstood the meaning of impedance mismatch. Impedance mismatch refers to a having sepearate logical representations for an object in the database vs. your application.

Quick Example:
Imagine an instant messaging application that deals with User and Message objects. The User can has an array of other Users that represent its contact list while it has a vector representing a log of all the Messages it has ever sent.

In an OODBMS based application I'll interact with my User objects and Message objects as if they are regular objects and the only difference between accessing them from the DB and accessing them regularly is that I'll first retrieve them from some Collection class (Map, Set, Tree, etc) before using them.

In an RDBMS based application, these will be stored as tables. Since I can't have multivalued columns I'll need to create a contact_list message table each that has the user_id that owns it as a foreign key. Thus everytime I want to perform an operation that requires populating a User object I need to join 3 tables or perform two seperate joins of 2 tables, then I get back a RecordSet (or whatever similar structure depending on what API you are used to) then I have to iterate through the RecordSet populating my Message and User objects in my application before I can get any work done.
That is an example of impedance mismatch, not the fact that Strings are unicode in Java but may be ASCII in the database or the other examples that you proposed.

[ Parent ]
Theoretically (5.00 / 2) (#45)
by KWillets on Fri May 04, 2001 at 12:32:16 AM EST

The concept of a tuple (or table) in a relational implies that it should be in a contiguous block of memory.
Check out Sybase IQ, if it's still alive (been a year or two since I last looked). This puts each column into a compressed vector (I think it's a bitmap, or else it enumerates the values of the column and maps them to int's). Complex joins are very quick this way. Numerous defunct RDBMS products have done similar things.

There are also join indexes, materialized views, and other storage tricks which lay out the data any way you want. Multidimensional DB's map n table columns to n dimensions in an array; the array elements are often just TRUE or FALSE to signify that that combination is in the table, or else it may be an int with a count of how many things fell into that bin (for tabulating/aggregation purposes).

I could write volumes about OO, SQL, and graph structures, but I guess my immediate response would be that foreign key relationships don't *have* to be key-lookup-based. I've suggested (to TimesTen once) that pointers be substituted for foreign keys; it's an obvious speedup in read time, with a bit of funkiness in update logic. However pointers can be error prone, which is why IBM forbade them in DB2 core table structures. I don't dispute that many RDBMS products are conservative, but I don't think it's because of the model. If anything storing the keys gives more room for recovery if the pointers go south.

(Also, you can use OID's as references in various ORDBMS's, eg DB2 comes to mind, although I think they still use keys as the OID's - back where we started. Oracle has OID's which are row id's. UniSQL (an early ORDBMS) used pointers though.)

You may be right about impedance mismatch - I meant to mention variance in logical structure as well (eg FORTRAN has an impedance mismatch with virtually anything). Lots of tools create objects via "Relational Views" and the like, which are queries wrapped in objects. I haven't tooled around with client end stuff like that in a while, though. But I think there are subtle problems in mapping to every language or application.



[ Parent ]

Doing it by hand (3.66 / 3) (#42)
by srichman on Thu May 03, 2001 at 10:26:49 PM EST

For a Java application where I work, we use a storage layer that was developed in-house that handles the object-relational mapping and has other nicities like SQL query abstractions and caching. The storage layer uses a configuration file that specifies the mapping, and supports various things you'd expect (like storing Lists, supporting gets on read-only and writeable object interfaces, etc.).

It may seem a little silly to reinvent the wheel, but our reasons were:

  • When we started writing this a few years back, commercial OODBMS's sucked. The crappiness of OODBMS implementations is a point that has been mentioned in several comments, but it's key to note that the quality of today's commercial implementations is in many cases irrevelevant. Most databases in the world are running under legacy apps, and here we can use the word "legacy" with a wink to include applications just a few years old. Switching to an object-oriented solution is just not an option for most of the world.
  • Queries (again, as others have mentioned). We need to support lots of complicated queries, both within our application and in offline (non-Java) reporting. This, in my mind, is one of the strengths of a hybrid solution (i.e., do-it-yourself OO storage): you can put in as much object orientation and abstraction as is allowable given the needs (querying and otherwise) of your application.


Ok, so... (3.33 / 3) (#44)
by pb on Fri May 04, 2001 at 12:13:28 AM EST

This sounds pretty neat; basically all the database crud in an RDMS can be ignored because your OODBMS example is so tightly integrated with the programming language, that the data types are almost indistinguishable. I mean, it sounds kind of like serializing all your objects into a database, or marshalling without RMI, or something.

So... what kind of performance penalties do you see? And what happens when the object-oriented / inheritance model doesn't cleanly fit your problem?

...and *please* tell me all that COM.* goop is somewhat portable?
---
"See what the drooling, ravening, flesh-eating hordes^W^W^W^WKuro5hin.org readers have to say."
-- pwhysall
"COM.odi" in Java? Think "org.kuro5 (3.00 / 1) (#47)
by pin0cchio on Fri May 04, 2001 at 12:59:19 AM EST

and *please* tell me all that COM.* goop is somewhat portable?

Java's COM.odi.* has NOTHING to do with Microsoft's Component Object Model and everything to do with odi.COM.

Java namespaces that begin with Top Level Domain names are reserved for those who have registered a second- or third-level domain; a package name starts with a reversed hostname. com.* is just the Java namespace equivalent of the ICANN namespace *.com. For instance, K5 is allocated the namespace org.kuro5hin.* because it registered the domain kuro5hin.org with an ICANN accredited registrar.

The general format for an Internet-namespace Java class name is: host name in reversed order . username, if developer does not own the host name such as on GeoCities or a mail server . name of client and/or product . other elements as necessary to classify the class . class name


lj65
[ Parent ]
Does this work for all domain names? (none / 0) (#58)
by donky on Fri May 04, 2001 at 04:39:34 PM EST

Hmm.. yeah, this is off-topic, but I would still be interested in finding out. Most programming languages do not allow the character '-' - so lets say that I have a domain name with one in. And I do, "nameless-sorrows.org".

Is "org.nameless-sorrows" a valid namespace name?

[ Parent ]
No (none / 0) (#63)
by greenrd on Sat May 05, 2001 at 04:13:37 PM EST

It doesn't, you're right - that was a flaw in the Java design. So e.g. working-dogs.com has to use com.workingdogs...
"Capitalism is the absurd belief that the worst of men, for the worst of reasons, will somehow work for the benefit of us all." -- John Maynard Keynes
[ Parent ]
replace '-' with '_' (none / 0) (#73)
by pin0cchio on Tue Jun 12, 2001 at 09:30:52 PM EST

Is "org.nameless-sorrows" a valid namespace name?

No, but "org.nameless_sorrows" with an underscore is close enough.


lj65
[ Parent ]
RE: Ok, so... (5.00 / 1) (#48)
by Carnage4Life on Fri May 04, 2001 at 01:26:49 AM EST

So... what kind of performance penalties do you see?

Performance is typically better than RDBMS queries. This is from my experiences dealing with them and from experiences of others that I discovered while researching this article. Of course, since benchmarks are prohibited by almost all major DBMS vendors then I couldn't publish benchmarks even if I had any.

And what happens when the object-oriented / inheritance model doesn't cleanly fit your problem?

The implicit assumption in this article is that you are using an OO programming language. If you are using an OO programming language to create your application but your data model doesn't fit an OO model then there is probably something wrong with your design.

..and *please* tell me all that COM.* goop is somewhat portable?

Those are Java libraries, so it should work on any platform with a recent enough JVM. The same zipfile of ObjectStore classes that shipped with the Windows version worked on RedHat 6.2 with no problems. I wrote my application on Windows and transferred the binaries and ran it on Linux for my demo without having to recompile. Write Once, Run Anywhere may not have been as overrated as I once thought.

[ Parent ]
Architects vs Brick Makers (3.50 / 4) (#46)
by SPrintF on Fri May 04, 2001 at 12:45:15 AM EST

The problem with the OODBMS architecture is that designing a database with orderly, useful classes is beyond the ability of most programmers.

Most programmers are reasonably good brick makers. Give them a specification for a small, simple module that performs a single, discreet function, and with hard work and a little luck, they can eventually provide you with a useful "brick" of code. Give them a specification for something more ambitious, try to get them to design a system, and they'll deliver, not a wall or a barbeque or a cathedral, but a pile of bricks.

How many times have you developed a tight, elegant system, turned it over to the "support group," and watched in horror as rotted away in the hands of dolts who didn't appreciate the structure of the system, who didn't even understand that there was a structure to the system at all?

This used to bother me quite a bit, but I've come to accept that the average programmer isn't any smarter than the average joe. You and I might look at an OODBMS and immediately grasp its elegance and extensibility. The average joe will look at it, cry "WTF?!" and rapidly reduce the design to a pile of bricks. And "average" joes are becoming more and more the majority of the IT workforce, as the talent pool becomes thinned with knucklewalkers who entered the field because they heard they could "make great money in computers!"

We can try to come up with better and better tools. But we need to find a way to develop better developers.



Why I don't use it : (3.00 / 1) (#49)
by Betcour on Fri May 04, 2001 at 03:25:48 AM EST

Because I'm a PHP coder and :
a) There's no widely available, reliable & cheap (free ?) OODBMS around. The few I've heard about cost even more than Oracle... in the RDBMS there's the free PostgreSQL, MySQL and Interbase. What are the free OODBMS equivalent ?
b) PHP doesn't have any lib to interface to a OO database. This might be related to a) of course.

Of course I'm bored to death of writing object that are wrappers around SQL accessed-table rows... but what can I do ?

Ozone (4.50 / 2) (#50)
by kubalaa on Fri May 04, 2001 at 04:19:12 AM EST

I think php will be one of the last places you'll see an OODBMS interface, because it's object model is so weak and there's not really any support for RMI-type stuff. There is a free OODBMS for Java, though, called ozone. It looks pretty alpha, but I think it's usable.

[ Parent ]
Check out MATISSE (none / 0) (#67)
by crownie on Mon May 07, 2001 at 06:09:26 PM EST

I have been working with a company called Fresher, who has just release a 5.0beta release of a SQL Object Database called MATISSE. They have also release an open source PHP language binding for it.

Check out: http://www.matisse.com/matisse/development/ for more information.

[ Parent ]
Wishes vs. sad reality (4.00 / 4) (#51)
by mvw on Fri May 04, 2001 at 04:22:30 AM EST

Databases are mission critical systems. And yes, it is obvious that we need some apropriate database counterpart for our OOP languages and their complicated data structures that gives us

  • persistence,
  • fast and flexible queries,
  • handling of large data sets,
  • support for different languages (minimum: C++ and Java),
  • support for different operating systems (minimum: Win32, Solaris, Linux)
  • the means for distributing/sharing that data among different hosts, and
  • backup services

My claim is that no available OODB presently delivers this.

As a side note I want to emphasize, that part of the misery is that we start from various single host systems, and that we have no industry strength distributed operating system around, but that existing solutions are all but extensions of some kind to shove the present non-distributed systems in that direction.

You will note that while relational database systems have a less flexible data model than the OODBs, they (after decades of development) deliver many of the above points. DB2 for example runs probably from Palm to S/390. Plus they are well understood.

There is no reason why OODBs should not mature in the future but at present they lack.

My experiences with Poet were disastrous, it ran well under Win32 but was not up the task with Solaris. (Problems with the pre compiler and problems with the os neutral dump/interchange format). Similiar phenomenon (one platform current, other platforms lag way behind): the latest Versant version is available only for Win32 but not for Linux.

Linux: GNU C++ is a moving target. The existing Linux port of Versant needs a specific gcc version, otherwise the precompiler barfs. But that gcc version is not used anymore in present Linux distributions.

Objectivity and Versant have ridiculous size limitations, comparable to the 64k barrier in ancient DOS.

Have you ever tried to take your C++ data model, that makes use of such features like templates and multiple inheritence, and try to access that from a Java client?

I would like to continue, but have to leave now.


Regards, Marc

Excellent work, too bad you didn't cite Chris Date (4.00 / 1) (#52)
by fossilcode on Fri May 04, 2001 at 08:14:43 AM EST

Any rational discussion of databases usually uses the work of Codd and Date as a basis. It surprised me to find that such an excellent article (I skimmed your paper too!) would not have used Date and Darwen's book Foundation for Future Database Systems: The Third Manifesto as a reference.


--
"...half the world blows and half the world sucks." Uh, which half were you again?
Great article (5.00 / 5) (#53)
by Frequanaut on Fri May 04, 2001 at 10:57:11 AM EST


Nice article, it's great to see an appreciation for OODBMSs.

Before working for my current company, I worked at two places that used an OODBMS for their primary applications/products. Of course my current company sells one of the products mentioned above, so I can't be considered wholly impartial. :)

I see several reasons why the OODBMS paradigm hasn't taken off:

1) There are still people who don't appreciate OO, or don't know what it is.

2) An OODBMS is less forgiving than an RDBMS, and is harder to tune later in application development than an RDBMS. Remember, with an OODBMS you're object model is persistent, with an RDBMS the persistent object model is a bunch of tables. This is where the schema changes mentioned above come into play.

3) Lack of reporting tools. If someone like crystal would ever come out with a reporting tool that spoke UML or Java as opposed to ODBC this would be solved.

4) There is a whole industry surrounding the support and design of relational models. Database architects and administrators make big bucks. With an OODBMS the design of the data is done by the programmer. DBA's aren't too happy about not being needed.

5) Oracle, IBM and Microsoft don't have an OODBMS, so it can't be a 'real' solution.


Given those, I'd say that items 2 and 3 are legitimate problems that need to be addressed by the ODBMS vendors.

The good things about OODBMS:
1) As a c++/java programmer, I liked not having to learn and maintain SQL.

2)When it comes to performance against the relational guys, we win. hands down. Period.

3) Development is quicker and easier.

4) Smaller footprint/better scalability.

Any one concerned about the reliability of these products should think again. The biggest customers of OODBMS products are the telcos (Ok, Ok, don't mention the telco DSL service) who need subsecond response time and HA.




Relational Databases Considered Harmful (4.00 / 1) (#55)
by Daddy Gravity on Fri May 04, 2001 at 01:53:08 PM EST

H. Baker wrote an letter to the ACM in 1991 that made many of these point: Relational Databases Considered Harmful. I saw one poster mention XML disparagingly, which is understandable given much of the hype. However, if you serialize to XML you get a lot of the benefits of CORBA (cross-platform, cross-language) without the tremendous overhead of CORBA. And there are a bunch of XML-enabled and XML-native databases on the rise.

Why Aren't You Using EOF ? (none / 0) (#60)
by f5426 on Sat May 05, 2001 at 01:46:54 AM EST

Enterprise Object Framework (aka EOF) is an ObjC library that do a transparent mapping between a relational data source and ObjC objects.

EOF was the crowd-jewel of NeXT Software Inc for the enterprise market, and is, unfortunately, not present into Mac OS X (but may be in the future. Or may be not. Or whatever).

EOF uses all the nice 'reflection' features of ObjC to access the database in an object oriented way. Of course, it is independant of the database vendor. Of course, it supports several ways to represent common concepts, like class hierarchies.

I'm going on a long week-end in a few minutes. If anyone want me to post the examples written against EOF, drop me a note.

So I ask the question. Why Aren't You Using EOF ? (Or, more precisely, why aren't you using an Object Oriented Architecture on top of a relational database ?)

Cheers,

--fred


EFFICIENCY (none / 0) (#69)
by Alhazred on Thu May 10, 2001 at 09:53:18 AM EST

Say that 10 times. The author was correct when he stated that an OODBMS can provide something like 1 to 3 orders of magnitude of performance advantage.

RDBMS as a persistent object store is pounding a round peg in a square hole. Its just not efficient.
That is not dead which may eternal lie And with strange aeons death itself may die.
[ Parent ]
multiple language access? (none / 0) (#64)
by sesquiped on Sat May 05, 2001 at 06:03:07 PM EST

I'll first admit I have little experience in database programming of any kind. The one tiny project I did work on, though, involved using the DB to keep track of some data that would be updated periodically by a C++ program running on another server, and would be queried and displayed to the user by some PHP pages (which happened to be running on localhost).

My question is this: would this be possible at all with a OODBMS? In general, is it possible to use a OODBMS from more than one language at a time?

It seems to me that one of the main features of RDBMS's is their language-neutrality. You can update the DB from multiple programs running on multiple servers written in multiple languages, and then query it with multiple languages also. With all this object oriented stuff, you've just destroyed that property (or at least that how it appears). Granted, in many situations the DB is being accessed through only one language and an OODBMS might be possible. But what if you want to switch for some reason?

A closely related topic is types: Since the OODBMS is so close to the language/environment being used, it must have basically the same type system as that language. That is, same ranges for integral and floating point types, same string restrictions, same object model, including inheritence (single or multiple?), etc. Trying to use that with two different languages (say, Java and Python, or C++ and PHP) at a time seems quite impossible. At some point, you're going to have to do some explicit translation. Actually, that, to me, is where the RDBMS model makes sense: since the type system of any RDBMS is different from just about every language, you're forced to do explicit translation. The OODBMS model can fool people into thinking they don't need that translation, when they really do.

Relational is for queries (4.00 / 1) (#68)
by garzoid on Wed May 09, 2001 at 01:06:03 PM EST

This story is at least 10 years old. When I worked for Boeing Computer Services in the 80's and early 90's, I was part of the AI group. I learned OO using Common LISP, Scheme, and Smalltalk. When I made the break into the database group, I too thought this way. But over the years I have changed my mind. The hard part of building a system is getting the requirements correct. If it doesn't have to work, I can build any system pretty fast. Then there is the conceptual design. Getting the conceptual design correct is very hard and critical as well. Your advisor wrote the best treatment I ever saw on the subject ... Batini, S. Ceri, and S.B. Navathe, Conceptual Database Design: An Entity Relationship Approach, Benjamin Cummings, August 1991, 470 pp. If you have done a good job here, then the majority of your work is done (read "No Silver Bullet".) Coding past the impedance mismatch is not going to shave major time off of your schedule. Working with people who do not know how to program is a much, much, much bigger problem. Lastly, Relational systems were built to improve ad-hoc queries - something navigational dbms did rather poorly. You could get the data in but could not get the data out. Oracle picked up IBM's system R work and beat then to the punch with their RDBMS. But it was not DB2 that Oracle was trying to overcome, it was IMS. They needed to be able to compete with the transaction throughput of IMS. All the work that went into query optimization was directed to this effort. That is to say, to improve in RDBMS what it was worst at. But as your advisors most excellent book sited above demonstrates, it's pretty easy to use relational technology to build object persistence. And don't talk to me about inheritance. In the real world, you are usually surrounded by idiots. It's hard enough to limit the damage they do.

This is an interesting basic introduction... (none / 0) (#70)
by Alhazred on Thu May 10, 2001 at 04:01:10 PM EST

There are a LOT more issues than you have raised though.

For one thing RDBMS are everywhere and most of us must work in an environment where we rarely get to reinvent the wheel from scratch.

Yes in theory OODBMS have high performance in many applications, but what about when you need to build many-to-many relations? Now how about when you need to manage these relations in complex ways? Sure you can construct some very elaborate OO way to do that, and I HAVE done it myself actually, but its a royal pain compared to the functionality that an RDBMS gives you, and the efficiency you talk about can go right out the window.

On the other hand, sometimes OODBMS are great. I have used GOODS (a freeware OODBMS with fairly basic features but very stable and fast) as a backing store for Perl and Java. In fact it is quite possible to share objects between the two, and since it can be used in a client-server modality you can do some really interesting stuff with it.

When you need a lot of odd little bits of data that don't have a really simple to describe structure, an OODBMS can be great. Its very hard to deal with data that is very hierarchical and often extremely heterogeneous in nature in a relational system. BUT when you need to just deal with sales data or something like that where its lots of very regular stuff, SQL is still king.
That is not dead which may eternal lie And with strange aeons death itself may die.
Because I've got Tangram! (none / 0) (#71)
by mugwump on Fri May 11, 2001 at 11:03:02 AM EST

Tangram is an object persistence framework for Perl that allows you to treat your RDBMS as if it were an OODBMS. Very hot - check it out!


Warning: this post may contain traces of bullshit.
Why Aren't You Using An Object Oriented Database Management System? | 74 comments (70 topical, 4 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!