Slashdot Mirror
Why Aren't You Using An OODMS?
Why Aren't You Using An Object Oriented Database Management System?
In today's world, Client-Server applications that rely on a database on the server as a data store while servicing requests from multiple clients are quite commonplace. Most of these applications use a Relational Database Management System (RDBMS) as their data store while using an object oriented programming language for development. This causes a certain inefficency as objects must be mapped to tuples in the database and vice versa instead of the data being stored in a way that is consistent with the programming model. The "impedance mismatch" caused by having to map objects to tables and vice versa has long been accepted as a necessary performance penalty. This paper is aimed at seeking out an alternative that avoids this penalty.
What follows is a condensed version of the following paper; An Exploration of Object Oriented Database Management Systems, which I wrote as part of my independent study project under Dr. Sham Navathe.
Introduction
The purpose of this paper is to provide answers to the following questions
- What is an Object Oriented Database Management System (OODBMS)?
- Is an OODBMS a viable alternative to an RDBMS?
- What are the tradeoffs and benefits of using an OODBMS over an RDBMS?
- What does code that interacts with an OODBMS look like?
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 RDBMSsThere 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- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
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.
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.
- Validating a user.
Java code accessing an ObjectStore(TM) database
import COM.odi.*;
import COM.odi.util.query.*;
import COM.odi.util.*;
import java.util.*;
try {
//start database session
Session session = Session.create(null, null);
session.join();
//open database and start transaction
Database db = Database.open("IMdatabase", ObjectStore.UPDATE);
Transaction tr = Transaction.begin(ObjectStore.READONLY);
//get hashtable of user objects from DB
OSHashMap users = (OSHashMap) db.getRoot("IMusers");
//get password and username from user
String username = getUserNameFromUser();
String passwd = getPasswordFromUser();
//get user object from database and see if it exists and whether password is correct
UserObject user = (UserObject) users.get(username);
if(user == null)
System.out.println("Non-existent user");
else
if(user.getPassword().equals(passwd))
System.out.println("Successful login");
else
System.out.println("Invalid Password");
//end transaction, close database and retain terminate session
tr.commit();
db.close();
session.termnate();
}
//exception handling would go here ...
Java JDBC code accessing an IBM's DB2 Database(TM)
import java.sql.*;
import sun.jdbc.odbc.JdbcOdbcDriver;
import java.util.*;
try {
//Launch instance of database driver.
Class.forName("COM.ibm.db2.jdbc.app.DB2Driver").newInstance();
//create database connection
Connection conn = DriverManager.getConnection("jdbc:db2:IMdatabase");
//get password and username from user
String username = getUserNameFromUser();
String passwd = getPasswordFromUser();
//perform SQL query
Statement sqlQry = conn.createStatement();
ResultSet rset = sqlQry.executeQuery("SELECT password from user_table WHERE username='" + username +"'");
if(rset.next()){
if(rset.getString(1).equals(passwd))
System.out.println("Successful login");
else
System.out.println("Invalid Password");
}else{
System.out.println("Non-existent user");
}
//close database connection
sqlQry.close();
conn.close();
}
//exception handling would go here ...
There isn't much difference in the above examples although it does seem a lot clearer to perform operations on a UserObject instead of a ResultSet when validating the user.
- Getting the user's contact list.
Java code accessing an ObjectStore(TM) database
import COM.odi.*;
import COM.odi.util.query.*;
import COM.odi.util.*;
import java.util.*;
try {
/* start session and open DB, same as in section 1a */
//get hashmap of users from the DB
OSHashMap users = (OSHashMap) db.getRoot("IMusers");
//get user object from database
UserObject c4l = (UserObject) users.get("Carnage4Life");
UserObject[] contactList = c4l.getContactList();
System.out.println("This are the people on Carnage4Life's contact list");
for(int i=0; i <contactList.length; i++)
System.out.println(contactList[i].toString()); //toString() prints fullname, username, online status and webpage URL
/* close session and close DB, same as in section 1a */
}//exception handling code
Java JDBC code accessing an IBM's DB2 Database(TM)
import java.sql.*;
import sun.jdbc.odbc.JdbcOdbcDriver;
import java.util.*;
try {
/* open DB connection, same as in section 1b */
//perform SQL query
Statement sqlQry = conn.createStatement();
ResultSet rset = sqlQry.executeQuery("SELECT fname, lname, user_name, online_status, webpage FROM contact_list, user_table" + "WHERE contact_list.owner_name='Carnage4Life' and contact_list.buddy_name=user_table.user_name");
System.out.println("This are the people on Carnage4Life's contact list");
while(rset.next())
System.out.println("Full Name:" + rset.getString(1) + " " + rset.getString(2) + " User Name:" + rset.getString(3) + " OnlineStatus:" + rset.getString(4) + " HomePage URL:" + rset.getString(5));
/* close DB connection, same as in section 1b*/
}//exception handling code
The benefits of using an OODBMS over an RDBMS in Java slowly becomes obvious. Consider also that if the data from the select needs to be returned to another method then all the data from the result set has to be mapped to another object (UserObject).
- Get all the users that are online.
Java code accessing an ObjectStore(TM) database
import COM.odi.*;
import COM.odi.util.query.*;
import COM.odi.util.*;
import java.util.*;
try{
/* same as above */
//use a OODBMS query to locate all the users whose status is 'online'
Query q = new Query (UserObject.class, "onlineStatus.equals(\"online\"");
Collection users = db.getRoot("IMusers");
Set onlineUsers = q.select(users);
Iterator iter = onlineUsers.iterator();
// iterate over the results
while ( iter.hasNext() )
{
UserObject user = (UserObject) iter.next();
// send each person some announcement
sendAnnouncement(user);
}
/* same as above */
}//exception handling goes here
Java JDBC code accessing an IBM's DB2 Database(TM)
import java.sql.*;
import sun.jdbc.odbc.JdbcOdbcDriver;
import java.util.*;
try{
/* same as above */
//perform SQL query
Statement sqlQry = conn.createStatement
();
ResultSet rset = sqlQry.executeQuery
("SELECT fname, lname, user_name, online_status,
webpage FROM user_table WHERE
online_status='online'");
while(rset.next()){
UserObject user = new UserObject
(rset.getString(1),rset.getString
(2),rset.getString(3),rset.getString
(4),rset.getString(5));
sendAnnouncement(user);
}
/* same as above */
}//exception handling goes here
Proprietary
- Object Store
- O2
- Gemstone
- Versant
- Ontos
- DB/Explorer ODBMS
- Ontos
- Poet
- Objectivity/DB
- EyeDB
Open Source - Ozone
- Zope
- FramerD
- XL2
The gains from using an OODBMS while developing an application using an OO programming language are many. The savings in development time by not having to worry about separate data models as well as the fact that there is less code to write due to the lack of impedance mismatch is very attractive. In my opinion, there is little reason to pick an RDBMS over an OODBMS system for newapplication development unless there are legacy issues that have to be dealt with.
My impression is that the relational model of databases is more natural to most DBAs than the object oriented model. Object oriented software tends to have a large nunber of derived types, and furthermore operator overloading (or function overloading) makes it impossible to read a snippet of code and really know for certain what it does. For certain applications (e.g. management of large data sets and low level systems programming) these features do not provide a sufficient "win" to offset the additional complexity and overhead. The competing paradigms in programming language design that I think are most compelling are:
- Procedural languages (and assembly language)
for precise control of the machine and
mapping onto hardware.
- Functional Programming (e.g. LISP) for
rewriting and filtering of inputs.
Many scripting languages do some of this.
- OOP for providing transparent abstraction,
encapsulation of data and programs,
information hiding, and code reuse.
- Declaritive Languages (e.g. Prolog) for goal seeking programs using logical deduction
- Relational databases for large data set
management and manipulation.
Remember that the art of picking the right tool is critical to doing a good job.You had the slickest OODBMS. Well, that's one adjective. You also had (probably) the least reliable and worst supported OODBMS around.
I already posted in response to an earlier thread cataloguing my team's woes with Objectstore.
OK, you faulted in objects rather than overloading -> but you have to get that right if it's not to cause major havoc. Our platform was HP-UX 10.20 and we had one helluva time with Objectstore and our C++ compiler. Coredumps on demand. An endless stream of patches and Objectstore consultants.
Your product had real difficulties with exception handling and that HP compiler and we couldn't stop using exceptions because we also used Orbix and it needed to use them.
I am glad you acknowledge your scalability and concurrency problems - we ran into them with 1GB stores.
Had Objectstore been robust (let's forget about scalability for the moment) it would have had a good chance of being used throughout our company's telecoms apps dept. (This was one of the world's largest software companies). As it was, whenever anyone called us asking our advice about Objectstore they ended up using Oracle.
Are you sure that your lack of market penetration was not fundamentally because none of your customers had a good word to say about your product?
I used to be an OODBMS bigot because of academic influences from grad school. Then I defected to the dark side :-) Actually I was doing compiler work, got laid off and these guys hired me to figure out how to bind their database objects to programming language objects. Finally I saw the light (in the dark side) and am now a complete Relational DB person.
The question to be asked (as an astute poster remarked) is why not RDBMS or ORDBMS ? I invite you to read Mike Carey and David DeWitt's 1996 VLDB paper "Object Databases - A Decade of Turmoil". You can probably get it from Citeseer.
Modern ORDBMSs are coming along very fast - they still do have some impedence mismatches, but they're going away really fast. As far as I see, "ease in programming" is the best reason for an OODBMS. DB2 UDB lets you create structured types with inheritance in the engine. You can use these types to create typed tables as well as typed columns. You can write your own methods - dynamic dispatch coming soon. You can extend our index manager with user-defined schemes and write your own predicates. So your queries don't look ugly any more.
The idea behind an RDBMS is really to separate the "how" of getting data from the "what" the application needs. This difference is crucial. It gives the engine all the room to find the most efficient way to access data. The relational model gives sound theory and lets us reason in really complicated ways. The ODBMS paradigm is to force application developers to traverse the data and the relationships involved. This locks you into a physical database design, and again affects performance.
Transaction management with different isolation levels are a good thing ! Relational databases are great at recovery of your data using log information. Well the good ones are :-)
It's a red-herring to wave a flag and say "OODBMS support indexes". Really without a proper query language what they support are hash indexes. Try to do a range query on those things ? BTW, OODBMS also support an Object Query Language .. and unfortunately you can't do as much as you can with plain ol' regular SQL ..
The big place where RDBMS wins over ODBMS is set-theoretic operations. Not everything is a simple traversal ! Consider an operation where you want to find the average salary of a bunch of employees that satisfy a particular criterion (in a salary range). Traversing a collection using pointers is terribly painful. Instead when you let our relational engine do the thing, bang it goes sucking page after page from the disk and really giving great performance. In addition you could have things like materialized views to precompute intersting results (and letting the compiler compensate over them appropriately).
Finally a lot of people take for granted that an ODBMS is "superior" and it's stupid business types who prefer an RDBMS. Actually, academia has well and truly come to the conclusion that RDBMS technology is the way to go.
Advice to the pure ODBMS camp: Get with the program. There are many great ideas in ODBMS technology, but the ability to support a declarative query language and separate access patterns is really crucial. Instead of beating the hoary old chestnut your best bet is to invest in an XML query engine. XML queries are coming a long way and you can do traversal operations pretty well with that.
Okay .. the debugger calls. Later.
Funnily enough my name isn't Anonymous Coward but given that my former employer still develops that product (although it uses Objectstore no longer) I don't want provide any way of someone figuring out who that company was. Telcos paid millions of dollars for that product and I wouldn't want it getting a bad reputation.
I find it hard to believe that databases over 1GB were possible on HP-UX 10.20 (32 bit address space) given the way Objectstore handled memory and also how much memory a user process had access to (only 1GB in most cases due to the four quadrant architecture of HP-UX - although I accept under certain circumstances you could get two quadrants (2GB) but those circumstances didn't apply to Objectstore).
I remember that when we got bigger than 600MB our problems began.
It's all coming back now. Objecstore grew from the top of the address space down didn't it? So when your store got too big there was a collision between your store and your application code. Or something like that.
One way to look at OODBMS is the second coming of IMS, the old IBM hierarchial DBMS.
I do Java programming (I hear boos and hisses from the peanut gallery, but I persist...) and could use a seamless way to store state of my object hierarchies, but OODBMS haven't been it. (The wag will say at this point that I should be using Smalltalk, which has this seamless storage, but I duck this brick and go on my way).
I used to work for a very large software company and we used Objectstore on one of our apps (telco related).
Every single person on the team agreed that it was the biggest mistake we ever made. Had we been a small company (not funded by a massive corporation) we would have gone under very quickly. And this was a team of top notch developers.
Objectstore is (or was at the time, around 1998) a truly buggy, awful product. Because we were backed by such a large organisation we were able to fund the massive delays Objectstore introduced (just before release, guaranteed, there would be a series of showstopper bugs in Objectstore that the support guys at Objectstore (whom we were paying a small fortune for a support contract) would take forever trying to fix (and inevitably get it wrong - we had patched patched patches). The platform was HP-UX BTW.
In our tests, Objectstore was fine with small stores but when we hit production (with heaps around 1GB) it couldn't handle it.
If you make an error in your code your store is more often than not corrupted. Data integrity is not Objectstore's strong point. And IIRC you cannot restore your store online. This resulted in huge downtimes for an application that was supposed to be 24x7. I think many people would be prepared to take some performance hit in order to have data integrity.
There was no great story on schema migration either.
Objectstore forces the developer to understand intimately how it is going to lay out objects within the store in order for you to get even decent performance. IIRC every time it touched a segment it loaded everything from that segment (it is several years since I've looked at Objectstore so I might be forgetting the salient details).
We dumped Objectstore after a couple of releases and moved to Persistence with Oracle. I also left the company so I don't know in detail how that went but I think it was much more robust.
I would like to add that I do think that *orthogonal* persistence is something that is very interesting indeed (see the Java implementation with P-Jama for example).
However, Objectstore is by no stretch of the imagination orthogonal and the quality of its implementation does no service to OODBMSs in general.
P.S I do not and have never worked for any database vendor or company in competition with Object Design.
Ok only one disadvantage with this OODBMS, a system wide recompile EVERY time you make a schema change. Umm, that's a pretty big disadvantage in my book.
Database Debunking has some great arguments against OODBMSs. Basically, it comes down to: data independence, no single rational object model, and the strong mathematical (set theory) foundation of the RDBMS.
Object theory is still too... undefined.
Microsoft is to software what Budweiser is to beer.
Great job, Carnage4Life!
:)
I didn't think I'd see the day when someone got actual content posted on Slashdot.
Or, for that matter, that you'd post a Java article that I thought was somewhat interesting and useful...
Anyhow, wouldn't it be easier to integrate all this with C? Especially considering the huge body of existing code, and the well-known primitives involved.
And are there any less proprietary OODBMSes out there that anyone would recommend?
---
pb Reply or e-mail; don't vaguely moderate.
pb Reply or e-mail; don't vaguely moderate.
Most of my applications are insulated from the actual RDBMS. I usually define all of the data-primitives I'd have in a given project, and only make RDBMS calls from this layer. The application itself only makes calls against this layer instead of being burdened with directly operating on the RDBMS.
Besides being better for portability, it also means that the application isn't tied to the actual RDBMS. It can easily be made to speak to something that may naturally expresses it's dataset, if necessary. This is no small feat. It means that IT DOESN'T MATTER WHAT THE UNDERLYING DATABASE IS. It could be a freaking plaintext file or it could be something ludicrously complicated.
I'm totally not amused by the Objectify-Everything mindset. This is a very difficult perspective to have, FWIW. All academics teach OOP as the "one, true, way." and in practice, people believe them. In practice, they also find that it's not the silver bullet that it's trumped up to be. Regardless, saying that you think it's bullshit leads most people to the conclusion that you're an unwashed uneducated fool.
Oh well. I never accused programmers of being open-minded.
As I understand, EROS is adding a rdbms but by its nature OODBMS would be a more logical use of its properties.
I actualy can't wait for an EROS OODBMS Network Data Storage system. I think they were meant for each other but it will take 10 years for people to comprehend it. I wonder if in 10 years when this idea is finnaly reaching Linux like momentum, if someone will think back and say "We could have had this 10 years ago".
~^~~^~^^~~^
Man, did you just use speed and ObjectStore in the same sentence? ObjectStore is not even in the same class as several other OODB solutions out there.
sigs are a waste of space
Reality is object-oriented.
Really? When the Sun rises, does it send messages to the birds to tell them to sing?
This is to cite an oft-used example of how absurd it is to think reality conforms to a message-passing model. It doesn't. That's partially why "design patterns" exist in the first place.. they're patches on things that the language model doesn't solve yet.
As for OODBMS', I'm an OODBMS advocate in some ways, I think they're great when in the hands of experts. But otherwise one tends to be able to get simple things done quicker with SQL, until a fully expressive ad hoc query capability is on these object systems.. (which is almost never the case).
Ditto for getting performance out of things... does your ODBMS have associative B-Tree indices built in? that work when your query is traversing over collections? etc. I've had to write these things myself in the past, and while pleasant, I don't think other people would share that opinion.
-Stu
They don't use just Objectstore. Lots of them use Informix too - like 8/10 of the world's traffic if you believe the adverts.
Although I had worked before on Oracle systems.
People have more confidence that they can find developers for Oracle than ObjectStore. But the same is true about COBOL programmers vs Java or C++ ones.
But this is why we have got consultants to help start the projects and get the design right. Once started on the right track, development usually goes a lot faster than in a traditional RDBMS environment.
I think the main reason people stick with Oracle and co. is that they prefer a known and tested solution like an Oracle database to store their business data.
This is the old "no one got fired for choosing IBM" argument.
By the way, there is no dba with ObjectStore (at least not in the way people think of them).
The optimizations are done by the programmers because the db layout is really dependant on your object model.
But the speed factor is something real which is why ObjectStore is doing so well with telcos (where speed is of the essence) with C++ applications.
On the EJB side, we really blow RDBMS out of the water. Oracle is nowhere near Javlin (EJB containers for ObjectStore) in term of performance...
Black holes occur when God divides by zero.
I agree about the complexity and skill availability arguments, it is still easier (and cheaper) to get several COBOL and VB programmers than Java or C++ ones.
But then you can always get a consultant to help with the design. And as a matter of fact, it will be faster to develop that way than having a bunch of COBOL developers put together some kind of server side app while some VB coders put the client interface together...
Having done both, I can tell you what kind of system scales and which one does not.
Have you done some EJB programming? You would be surprised how much faster and easier it is to go the OODB route.
My opinion on what the biggest problem really is, is mainstream recognition. OODB vendors are vulnerable to FUD from RDBMS vendors as much as Linux was suffering from Microsoft FUD two years ago. Note that for OODB systems (as for Linux 2 years ago) there are some good reasons to stick with the mainstream solution. Going the OODB route is far more risky (from a business decision making point of view).
Black holes occur when God divides by zero.
Yeah, there's a standard ... but what good is the standard if none of the vendors do more than implement subsets of the standard, and none of the vendors implement the same subset?
Are you moderating this down because you disagree with it,
We call it art because we have names for the things we understand.
--
http://kx.com
taylor:{+/y**\1.0,x%1+!-1+#y}
A lot depends here on what we mean by the OO in OODBMS. Even in programming, the meaning of object-orientation has changed through the years. And the problem of ambiguity is even greater with database management tools.
I am glad there are good and smart people working on a standard for what constitutes an OODBMS. I suspect it will be a few years before a definitive standard is completely figured out.
Consider, for example, some of the very different things people mean by an "Object-Oriented Database Management System":
Some people use it to mean "something which will give me persistence in the OO app I'm currently working on." For them a relational database management product with a few OO tools may be fine (assuming their objects are sufficiently simple).
Some people use it to mean "something that will give me the ability to tie behavior to persistent objects." For them good stored procedures (like Oracle with a third-party product for debugging stored procedures) may be exactly what they want.
Some people use it to mean "a DBMS which implements all the major features of current OO theory." A OODBMS which truly implements standards (as linked to in the original article) is what's needed for these people.
Some people use it to mean "something which will enable me to implement all ideas currently associated with advanced OO theory (including aspect-oriented programming) and anything which may be included in that theory in the future." A DBMS with a dynamic model of object-oriented-ness (along the lines of Perl's dynamic model of what OO is) would be required. I don't know if anyone's actually accomplished this, but I would be both impressed and interested if it's been done (especially if it's language-independent, assuming that's possible).
And some people use it to mean "a DBMS which is fundamentally object-oriented in its underlying structure enabling a variety of powerful table-creation tools." This can be accomplished with some of the better OODBMSs (depending, once again, on just what you mean by "fundamentally object-oriented").
Given all this, I suspect it will be a while before a clear definition is agreed upon. It may even come out of theoretical work in academia. Until that time, the practical reasons listed here will continue to be why many don't use OODBMSs. And the attractive features they offer will continue to be why some people will ignore those practical problems.
Oh, no! It looks like we're back to "it depends on the problem you're working on" just like so many of these debates.
Eternal vigilance only works if you look in every direction.
At first glance, I thought it said CONDOMS. I thought it was kind of a weird topic for Slashdot.
Software sucks. Open Source sucks less.
Actually, data loading/backend-type stuff is easier with an RDBMS, because data-entry is almost alway tabular anyway. However, once entered, it is usually easier to process it through an OO layer. The best way to accomplish this is to have a CORBA layer that the applications always use for talking to the database that actually incorporates all the business logic, but have the CORBA layer talk to an RDBMS.
I don't have a lot of experience with OODBMSs - I'd be curious exactly how they work. The closest I've worked with is PostgreSQL which is Object-relational. Are there any intro guides, especially to schema definition and stuff like that.
Is there a free software OODBMS?
Engineering and the Ultimate
The article says that 'impedance mismatch' causes performance loss. I don't see this as necessrily true. If anything, I'd expect the additional features (listed at length in the article) to cost performance...are any numbers available?
Whether an OODBMS or RDBMS is more appropriate depends on the situation, (and how good the particular database implementations are - you can read lots of stuff by Codd on how what most people think of as RDBMS's has more to do with implementations that what the relational model actually allows (for example, the One Data Model fits there - operations and behaviour should be part of the single model, they just aren't usually part of the database schema). As a general rule if your data structures are stringly tied to a particular application, you want an OODMBS, and if you want free form ad-hoc queries and flexibily changing applications, you want an RDMS.
But anyway, I just wanted to pick up on one point.
When you say "No Primary Keys: The user of an RDBMS has to worry about uniquely identifying tuples by their values and making sure that no two tuples have the same primary key values to avoid error conditions. In an OODBMS, the unique identification of objects is done behind the scenes via OIDs and is completely invisible to the user." that's just flat wrong (and dangerously so).
Object identity is important. If you rely on invisible Object IDs to wave a magic wand and handle it for you, you will almost certainly end up with a single real life object having multiple inconsistent representations in the database, so to avoid screwing it up you will need to do explicit defining of keys and checking for duplicates.
On the other hand, if you have a well defined keys in your Relational Database, there isn't a problem - the database won't _allow_ duplicates. In a worst case, you have to define artificial IDs in your RDBMS and you are back to the OID case except that you actually have control over them.
Of course lots of people do make a mess of choosing keys - but OIDs _don't_ solve the problem.
--
rant
The point of OOD/OOP is creating software that more directly reflects the problem domain of the system being constructed. Its for creating maintainable software fast (by directly implementing the model instead of having to twist the model to fit restrictions in the language paradigm). Encapsulation helps maintainability; inheritance and polymorphism help the reflection of the model.
This code is not necessarilly reusable. And any true Object Model is going to be very application specific and have very few reusable parts.
Reusability comes from a Component-design approach. Components are not (necessarilly) Objects. They can be used to implement Objects, but they can be constructed using non-OO techniques. Objects belong to a problem domain; reusable components might not.
--
You know, you gotta get up real early if you want to get outta bed... (Groucho Marx)
"But remember, most lynch mobs aren't this nice." (H.Simpson)
-- Joe
How do object databases perform as data warehouses? Intuitively, it seems like OO would not natively be efficient at aggregating data, and would be forced to rely on application-level code for any analytical processing. Or am I missing something?
Why'd you say 'burma'?
Why'd you say 'burma'?
--I panicked.
No one ever got fired for buying oracle/db2. At the moment why would you bet the farm on a wonderful "new" (yes I know it's not really new) technology like this, especially when the previous incarnation of oodbms failed in the early 90s (I was involved with one of these, a complete disaster) when you can get nice object relational mapping tools and use a good and proven solution?
development.lombardi.com
You wrote:
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.
If I simply want a persistence mechanism for objects (and will access these objects via a pre-designed application), then sure, an OODBMS makes sense. However, if I understand a priori that all kind of queries will be executed against the data, I need to design accordingly, and here, the relational model is superior to the OO model: fast access of the data depends on exposing the possible queried fields.
Without this exposure, if I store the data as objects (that have references to other objects), then I might have to traverse ALL the objects to get the result set of some query, and this highly inefficient. So the response to that might be, "then expose all the fields that might be queried," and, thus, you are reverting back to a relational structure...
Twelve-and-three-quarter inches. Unyielding. This wand belonged to Bellatrix Lestrange.
3 Things:
If people could learn SQL which is completely unrelated to any other aspect of their programming experience then adding OODBMS techniques as a skillset would be trivial.
Speaking out of years of DB experience, learning OO techniques are not trivial. SQL is fairly easy to learn - even for a procedural programmer. However, inheritance, polymorphism, just to name a few are not simple concepts to grasp.
Of course, if people don't realize that alternatives to RDBMSs exist then they won't learn these techniques.
Ugh. Databases should be designed for 2 main reasons really.
1. Speed. Get in and get out fast!
2. Redundancy or data protection.
Everything else is just nice little utilities bolted on (cept maybe indexes).
I been programming in Java for almost every work day for the past 4 or 5 years and while I've seen Java performance increase, to me, writing a DB in it is pretty ridiculous. Granted, an OO db could be just a easily be (or maybe not) written in C++. However after much review and time and just learning how to write good software over the past years, I'm not quite convinced that OO is 100% the way to go. However, it has a place.
That is more important because management can't find people who have these skills if developers don't go out and learn these techniques.
With all do respect, I have worked with very few managers that were worth much. I've seen so many mangers jump at anything OO without knowing what they're talking about. So I trust me over them to make informative decisions about software.
Imho, make good software not hype.
I was a database administrator for 3 years, and I think I changed the schema of an existing table exactly once. Now, I'm not totally sold on the idea of OODBMS, but if it has genuine benefits, then making schema changes harder would not be that bad considering how often they tend to occur.
Ben
So I take it you've only worked on pristine new projects coded in a vacuum, then? While I've never known anyone (well, anyone who knew what they were doing) to start putting data into a new database before designing their app, I've encountered many cases of new apps being written to use existing databases, generally either because the new version needs to be backwards compatible with the old one or because the need has arisen to look at old data in a new way.
... need to redo this "study".
Object databases are cool, specially from a programing standpoint, but there are a lot many disadvantages than the single one you listed, including : cost, familiarity (most people are not), less vendors (and open source alternatives), legacy databases (migrate or build bridges ?), etc.
Whenever you compare technologies, if you only find 1 disadvantage, you have probably not looked hard enough.
- sigs are for wimps.
was the ability to use already-existent tools to do data mining, reporting, & other similar (not necessarily insignificant) activities...
in all cases that we had gone through rigourous prototypes of products and used ODBMS', it always seemed to come down to the same few things:
1) critical mass (everyone already knew the relational databases very well)
2) tool robustness (there are a wide variety of good tools (most 3rd party supplied) to MANAGE relational instances. i'm referring to more subtle circumstances than managing users & schema here)
3) reporting and data-mining was ALWAYS more difficult (usually by an order of magnitude or more).
now, my last involvement in a prototype is YEARS ago, so i'm absolutely positive things have changed...
the reality remains that people haven't yet gotten by what they learned in their first few experiences and simply haven't re-examined the landscape, just like myself...
a weak excuse, but i'm certain this is a more common answer than we'd all like to admit.
just my 0.02.
Peter
You should be, if you're a software engineer. If you're just a code monkey then it doesn't really matter as you don't create the design, just bang out code from a specification.
Guess my ranting overrided (OO pun! HOORAY!) my Simpsons attention.
Adding columns and design changes are fact of life. Until it is as easy and safe as relational - OODBMS apps will definitely be widespread.
When OODBMS store their data in an XML document style format is when OOBMS will take off since the dtd can be written with versions in mind and older objects can still be understood with relative ease.
Great article. At this point, it's the only article rated higher than 2 and that's fully deserved.
But I have some additional points:
6. The world is not object oriented. Even if oo is a usefull tool, it is no silver bullet.
7. RDBMS are proven technology and rather well standardised, OODBMS aren't. Currently there is a proposal for a standard (java data objects), but even that only addresses one plattform.
Everyone knows SQL; nobody knows OO.
:-)
Well, I don't know about anyone else around here, but I knew OO before I'd even heard of SQL.
I know that C, Perl, etc are still very popular languages, and deservedly so, but C++, Java, etc are also extremely popular. I think OO has been around long enough now for there to be little excuse for people not to know anything about it. They're even teaching it to the Physics students at my old university, fer chris' sake!
(Although not until after I'd been forced to learn Fortran, mind you...)
Cheers,
Tim
It's official. Most of you are morons.
Ok, I have to admit I'm not a relational scholar. I've read Chris Date's An Introduction to Database Systems and Foundation for Object/Relational Databases : The Third Manifesto. Both contain excellent reasons NOT to using OODBMSs for most database applications, at least in the form you refer to. Here are some of my observations on OODBMSs,
Composite Objects and Relationships:
OODBMSs may be able to outperform an RDBMS for a specific data model, but ONLY using queries and transactions that are defined up front in your modeling/design process. Relational systems will often perform better when all of the possible queries/transaction are not known up front. (as is often the case)
OODBMSs often fall down when their datasets exceed the amount of RAM in your system. Because the relational model is mathematically well defined, RDBMS implementers can build generic query analyzers that can often find an optimal data retrieval path for a large set of queries that aren't known up front. Also, you can tweak a query's performance using indexes and storage specifications. This is much harder to do in OODBMSes - which don't have a well defined mathematical model.
Date's Third Manifesto shows the proper future for DBMSs, IMHO - add OO to RDBMSs.
Class Hierarchy: Data in the real world is usually has hierarchical characteristics.
In the real world, data can be modeled hierarchically, but often shouldn't be. Imposing a hierarchy limits you to viewing the world through that hierarchy.
Improper OO modeling can cause a ton of headaches. In your Employee/Manager hierarchy, what happens when an Employee becomes a Manager? Does the object change its type on the fly? Say you have a MangerList that contains a list of Manager objects (and only Manager objects). What happens when a Manager is demoted to Employee? Is the OODBMS smart enough to remove them from the ManagerList dynamically? Or do you have to write code to auto-magically remove them? Or do you destroy the Manager object and recreate them as an Employee?
Circumventing the Need for a Query Language:
Without a generic query language, any OODBMS "queries" you perform must involve massive amounts of recursive pointer chasing. It is possible to use query languages in an OODBMS but they have a much harder time optimizing the queries due to the lack of a formal mathematical model for OO and the lack of emphasis on normalization.
No Impedence Mismatch
This is not a problem with the relational model, it's a problem with the interface layer you are using (ODBC, ADO,..). These interface layers are designed to be generic to all RDBMSs, this causes the impedance.
No Primary Keys
My primary beef with OIDs is an OID defines a value that has no meaning to the object it represents. It is extra information that takes up space. Often OODBMSs have to resort to 128-bit or larger values to be able to generically identify every possible instance of every class in a system. These large values can greatly increase the storage space needed for objects. Say I have a class that just has one 32-bit integer member. In an OODBMS, the space required for an OID is many times larger than an instance of the class itself!! (Very inefficient!) Also, every lookup of an OID potentially requires a search through every object in the system, not just the primary key of one table. For large datasets this is a killer.
Also it's incorrect to say a user of an RDBMS has to worry about primary keys. It's the designer of a relational data model has to worry about keys. A user just uses the data model.
Defining primary keys is one of the easier tasks in relational modeling, IMHO.
One Data Model
I agree, current RDBM Systems don't model behavior very well but that's not a fault of the relational model, it's the fault of RDBMS vendors. Transact-SQL sucks ass, PL/SQL isn't much better.
Well, Anonymous Coward, if that is your name, "none" is provably false. All I can say is that your experience was atypical based on the information I saw. Databases over 1gb were common, and most customers I met were very pleased with tech support.
There is no limit on the database size. The limit is on the amount of mapped memory space in a single transaction, 1gb in your case. You sometimes have to plan things carefully, (e.g. judicious use of ObjectStore references), to avoid running out of address space.
As someone else has pointed out, OODBMSs require a very different skill set. The problem isn't that your typical SQL developer didn't have these skills. The problem is that the things were ever referred to as database systems.
If you walk into a potential customer selling a "database system", then the database guys come and hear what you have to say. They ask about SQL support and point-and-click development tools. They are going to be looking for very high levels of concurrency, at isolation levels below serializable.
Selling a "database system" meant that once we got past the early adopters, we were selling against Oracle and we hit a wall. What we should have done from day one was to sell persistence for C++. We did start out like this, e.g. trying to convince ECAD vendors to build their products on top of ObjectStore. That had some limited success because the customers knew that they needed persistence, but they were C/C++ hackers at heart, and an RDBMS was a poor compromise. A "database for C++ with no impedance mismatch" sounds great to someone writing a 3d modeler. We then went on to apply the same logic selling to satisfied RDBMS users without changing our strategy, and that's when things stalled.
That strategy was necessary in some ways, because we were venture-funded, and the VCs weren't going to be happy with a small niche. They wanted something that would get into every insurance company and bank. However, by aiming high and failing (by VC standards), we abandoned our natural market too soon and avoided becoming a small success in that market.
> If you store your data by maintenance method
I don't really know what you mean.
--
Leandro Guimarães Faria Corsetti Dutra
DBA, SysAdmin
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
> It is interesting to see that a posting with so many wrong statements receives such a high rating here.
It seems that each of us have different ideas about what's right and what's wrong, so let's get over such self-serving statements and go over the issues at hand.
> Reality is object-oriented. We use objects in our modern programming languages.
As far as I know reality may be represented by objects. It makes no sense saying that reality is this or that oriented, since apart from God no one can ever know what He was oriented to when he did create.
Seriously, reality can be represented by objects. It can be represented by relations also. Even if objects are convenient for some programming domains, it isn't for data storage and retrieve, except if your program will never change *and* it is object-oriented. It's surprising to learn how many programming gurus, and specially database gurus, steer clear of object-oriented programming, rather keeping with other models of programming like the functional or the structured ones.
> Why should we flatten these out to tables with unnecessary keys...
Why should we complicate relations with objects, if we can store data-independently?
Please, you are repeating OO jargon without explaining nothing to me. As I never saw much sense in OOness, I will need better teaching than this.
> Relations between objects can be maintained transparently within the database.
This isn't the issue. The issue is that these relationships are maintained physically in the database, thus getting against the Information Principle. In contrast, relational databases have no physical links. All relationships are a result of data kept in common by different relations. I won't explain here what is a relation; you should read Chris J Date's An Introduction to Database Systems for that.
> This is common-sense and there is no need to write scientific papers about it.
It is common sense for uncommon OO programmers, not for DAs, DBAs, functional or other non-OO programmers and common people like me.
The fundamental issue of OO is that is an over-extension of some simple programming rules-of-thumb. When they got the full extension they have today they got much more complicated than the surprisingly simple scientific papers that were published about relational database model theory, like E F Codd's paper.
> You can design data by writing classes in your respective programming language.
Not so fast. I want my data in my database, in a well defined and theoretically sound *data* sublanguage, not only in a programming language.
> [independence of the logical and physical layers of your database]
> Where do you need tables here?
> Class members define properties.
> Methods define behaviour.
If you want to compare relational databases to anything else, it is better to think relations, not tables nor entities or relationships.
Seriously again, relations are a logical representation. With this logical representation of data at users' (and programmers') hands, you can lay your data physically whatever way you want, even by using pointers if you like. This way you can optimise the physical layer for performance or availability or thoroughput or whatever balance of whatever goals, while keeping data logically organized, easily accessible and readily available to access plans created by a good query optimizer.
> [shifting the performance optimization issues to the DBMS' optimizer]
> Object databases also use optimizers to analyze queries.
But your access paths are predefined. The user has little freedom to discover relationships between different data, ad hoc queries will have weird access paths and little possibility of optimization. And if you ever need a schema change, you will have to rewrite lots of queries.
> [any schema change do not only need an application recompilation]
> There are object databases that manage schema versioning automatically.
> Our product simply stores a superset of all used schemas.
This won't fly. This is schema accumulation, not change. You will have data stored in many different ways, and users will find ways of wanting schema changes that can't be efficiently stored anyway.
> Wrong. Our object database is not multi-user as of today
Then you haven't even faced the very issues relational theory was created to solve. First read and understand Codd's paper above, then we can talk. Write me privately by email, or better yet read also The Third Manifesto, then Database Debunkings, and then we can talk.
> By the way: Do you typically have different tables for different users?
Even in quasi-relational SQL each user has its own schema. And this schema can contain base relations, derived relations including named ones (views), and synonyms.
> [rethink the data access path]
> Reengineering is a terrible problem with relational databases.
I've been working for years with weak, quasi-relational SQL and even with this poor tool I've not faced this problem of "reengineering". I now you have a product to sell, so it may be hard to forget marketspeak, even more actually acknowledging some fault, but what do you mean really by reengineering? AFAIK this is a management nineties' regurgitation of Operations and Methods ill digested with some Data Processing thrown in, not a CS word.
> Strings are not typesafe, so you have to parse the entire application
Stop! Stop! You're killing me!
Seriously, strings are strings. If SQL doesn't do all type checking it could, it is no fault of strings per se, much less the relational model. And it has no bearing in relational data independence. When you change a data type, you have a different relation, there's no way of shielding a typesafe language from that. Some data sublanguage may provide some shortcuts to such modifications, and even do some automatic type casting, but this is not a database model issue.
> [which should give us practically all of the advantages of OODBMSs without their cons]
> We are going the other way. We want to provide all the
> relational functionality that you wish with
> our object database. We might finally end up
> with very similar engines.
Not at all, because you haven't yet understood the fundamentals of the field.
--
Leandro Guimarães Faria Corsetti Dutra
DBA, SysAdmin
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
The issue is that OODBMSs do not conform neither to current database best practices, nor to theory.
Relating to best practices, you should know already from other, better-rated comments in this thread: you should design your data before your application, OODBMSs make it hard; you should strive for independence of the logical and physical layers of your database, keeping data independence and shifting the performance optimization issues to the DBMS' optimizer; OIDs hinder the designation of candidate keys, of which the primary key is a special case, and thus hinder a lot of data integrity checkings that should be done by referential integrity. And we could go on and on.
As for the practical implications of not conforming to these best practices, any schema change do not only need an application recompilation, but also that you rethink the data access path (also known as a query's access plan); you won't be able to keep several logical schemas to different users, and the identity of the user's view with the physical layout will force you to optimize only for the most common case, instead of leaving it up to the DBMS to create the best access plans.
All this is much better explained in Database Debunkings, a site co-maintained by Chris J Date, author of the best database books I've ever read; you can find a list of his available books also there.
As for theory, there is no real substitute for the relational database model theory. As Linus Torvalds thinks that microkernels were a good idea but misguided, wielding no practical nor theoretical improvements, so OODBMSs sounds nice but offer no real improvements over RDBMSs. This is not to say that everything you will ever need will be handled properly by your SQL DBMS. The point is exactly that people have went for OODBMSs because they thought that SQL was relational, and found it wanting. The problem is that SQL never was truly relational, just an approximation of it. Date has a whole book on it, called The Third Manifesto.
Summing up, what I am really trying to find is some proper implementation of the relational database model ideals, which should give us practically all of the advantages of OODBMSs without their cons. I have just been informed of Suneido, but have not investigated it fully... it's a pity it is Win32, not POSIX.
--
Leandro Guimarães Faria Corsetti Dutra
DBA, SysAdmin
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
Developers aren't the only ones who have to query the database.
Hear, hear! My first database-related job involved writing Crystal Reports against an Informix databse. I knew zilch about CR, SQL, and databases in general when I started, but I was up to speed in about a month (enough to do the job, anyway). I was working in suitland (the 'real' developers were elsewhere in the building); there was one former coder who was my manager, and one other report writer. EVERYONE else was nontechnical - MBAs or MBAs to be. ALl of them had a decent understanding of the database structure.
In fact, zope's OODBMS, the ZODB is usable without zope, see
http://sourceforge.net/projects/zodb/
We mostly use a custome OO Java layer over our database to drive our primary web application. But, occasionally, someone wants to crank out a reporting app with Perl. No problem, just load up DBI and whatever CPAN libraries you want. We have another app written in Python that hooks into the DB, equally easy. And, yes, we have our resident PHP fans who insist on using that for quick apps, so they use the mysql layer for their language and have no problem.
And, oh, did I mention that MySQL, which we're using, is free, fast, cross platform, and well tested by thousands of users over the course of many years? It also has tons of freely-available tools (GUIs, web apps, etc.). None of the OODBMSes can touch that (yes, I actually evaluated Zope and Ozone, the two biggest open source alternatives, and they don't come close to what we're looking for).
But, that said, I WISH we could use an OODBMS that was free or inexpensive (this is a nonprofit institution), cross-language (including scripting!), and standards compliant so that we could move to a competitor if we needed to.
In the future, we'll probably move to Java Data Objects (JDO), which provide an object-relational mapping layer over a traditional RDBMS, but without the complexity of full EJB. See Exlab's Castor project for more info.
--JRZ
Firstly, they only really make sense if your applications are OO. Mine are now, I use Zope and its OODBM is amazing (supports transactions, versions, undo etc).
It keeps things elegant, tidy and dev time is slashed considerably (perhaps 40% of similar things in PHP/RDBMS from my experience)
If you don't try them, you'll never know.
http://www.zope.org
Compare the TPC-C (OLTP) or TPC-W (web e-commerce) benchmark numbers for the OODB's to those of the RDB's. Well... you can't. None of the OODB vendors have done those benchmarks. They know they would suck. Or maybe they just know that the RDB's have this market sown up, and can't justify the investment.
Whatever reason, if TP is at the heart of what you do (as it is for MANY systems), you don't want to use a DB whose vendor can't or won't do the industry standard benchmark.
Actually, you can use objects with an RDBMS if you are using PHP4. The Serialize command will encode an object for storing in the database as a text string. The only problem is that you can't do any queries on the data in that form. Combines well with sessions though, I believe.
Personally, I find that there are very few things that actually work better as objects than as straight procedural code, but that's probably just a matter of coding style and language preference.
While OODBMS were an obvious choice to me for performance and ease of programming, my consultants told me that finding Oracle talent was so much easier than finding Versant talent (for example) that I would be wasting time and money using OODBMS. This is especially true of DBAs.
And that's precisely the same reason it took Linux so long to catch on in the enterprise, and why it still hasn't invaded small to medium businesses with only 1-2 network-savvy people. I'd love to switch to Linux fileservers instead of upgrading our NT boxes to 2k, but since we can't find anybody with the appropriate experience to manage them when I'm not around, we stick with the point-and-click OS's. Don't flame me for the decision, I'm just stating why we don't always switch to things we all know are best. (Reminds me of OS/2 for some reason.)
What's your damage, Heather?
I would have liked to see some example code for storing data into the OODMS, anyone have any?
Well, it is as good as SQL can get. You see, no vendors implement the same subset of that standard.
Ricardo da Silva Lima
The main reason our company has not used a OO database is that we have programs written in many languages - all of which can access the relational database via a common interface (SQL) into supported objects (recordsets) for every language we use. OODB's want to impose a class structure that may or may not be easy to support in a given language, and the overhead for such a class structure for say, a web page extracting data for display, would be excessive compared to running a SQL query and outputting the rows.
Sig under construction since 1998.
This reminds of the famous GOTO considered harmful issue.
Relational systems are useful for a wide variety of tasks specifically because they are limited in their expressive power. This limitation in their expressive power means that certain desirable properties are maintained.
The objects that are recognized in the relational programming model are scalars, tuples and tables. Most operations are closed on the set of all tables -- that is to say the take tables and produce tables. This means that you can compose operations in various kinds of ways and still have more raw material for further operations.
To take a more modern view of this: relational databases are about the reuse of facts. The process of designing a database is one of analyzing factual relationships so that eventually each fact is stored in one and only one place. This, along with the closed nature of relational operations, facilitates recombining these facts in various novel ways. I believe this is the source of the relational model's sustained popularity.
The cost is that the resultant model is not ideal for any single application. I believe this is the nature of the "impedence mismatch" -- you are dealing with an off-the-rack, one-size-fits-most-applications representation of data. Naturally, for complex applications with severe performance constraints, a more tailored representation is required.
I've never had the cash to hack around with OO databases, so I'd like to learn more. Do they support the kind of composition of operations that you get with relational systems? Presumably objects can be re-used in different applications, but how well does this work in practice?
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
So I wrote the above ..
Yes, the evaluations I did were circa 1997. It's quite possible that better things have come since then. However, I have also interviewed a couple of engineers from Versant and their description of their systems left a lot to be desired - of course that could just be them.
Oh btw, I not only did evaluations, I also played around looking at the internals of one of the academic systems.
I'm sure my employer uses/resells ODBMS systems somewhere. Big deal .. if my comments suggested that I think ODBMS systems will fade away - I don't. I just think to suggest that they will replace relational systems is stupid. I think we both agree there.
I agree with a lot of what you say .. however:
An Object Database is a far more general solution, it is childs play to make an ODBMS pretend to be an RDBMS the opposite is what is hard.
This is laugable ! Yes, it's child's play to get an ODBMS support "relational" operations - but it's impossible to support relational operations in any efficient manner even coming close to what a relational engine can do. Yes I'm biased, but I also have the ability to view engineering problems with objectivity. I submit that anybody who thinks performance isn't an important consideration for a relational system doesn't really understand the business and what relational customers want.
General solutions can't be optimized for specific usage, because they are general. By the time the relational companies are done building ORDBMS that really compete with us ..
We aren't really trying to compete with you if you are providing persistence for objects in an interactive application for CAD design. We are competing with you in caching solutions for web applications. I strongly believe that an ODBMS solution isn't scalable for a high-volume web application. You might get some performance wins when your load is low, but one thing you have to understand is the difference between performance and scalability. How on earth do you plan to support shared-nothing (or shared-disk) parallelism for instance ? I know of large trading sites which have clusters of 16 mainframe boxes which are white-hot. You cannot pump that kind of transaction volume through ODBMS systems.
ODBMS and RDBMS systems each have their own places. There is a small area where they overlap - and in that overlap area I believe ORDBMS will win because they offer the best of one and a "reasonable" enough amount of the other. The pure ODBMS market will definitely survive. How many vendors will be left, I'm not sure.
But most small shops' needs can be met with totally turnkey servers. (IMNSHO, YMMV!)
Technology -- No Place For Wimps! Grateful Dead and Jerry Garcia Chatroom -- http://www.wemissjerry.org
In the original article a number of OpenSource OODBMS where listed how do these compare with their commercial brethran, I use ZOPE and therefore ZODB a lot, one of the problems I see with it is it is so tightly bound to python (which in itself isn't a problem) but other than tools such as XML-RPC I can't get to and work with ZODB objects from, say Java. This seems to pidgeon hole this type of tool, to a very specific platform. (maybe one could to ZOPE RPC calls from Jython to a ZODB)
I asked the same question on K5, but got no takers: has anybody played with ZODB outside of Zope? insights/impressions?
I've had experience this term of using ObjectStore PSE Pro on an OODBMS course.. and I didn't like it much. The system itself is proprietary - which meant that I could only run the code in the labs with the software installed, and I couldn't take a copy home with me... The object types which can be stored within the database are limited.. for example, I couldn't store Vector objects within the database, which was quite annoying.. Bleh. Not much content to this post, just a vent about how crappy PSE Pro is, mostly.. ;)
Aren't you supposed to design an application before implemnting
it in any way including putting data in a DB? I've worked at two companies and
had a ton of projects in school and none involved implemnting the database
before the application was designed.
I'd like to know what world you are living in. In the real world, most databases
are legacy databases and FULL of data. I've had to design applications around
databases for years now. In my field (Programming for Engineers) the data is king
and people need to access it in multiple ways. True, if you are designing a
system from the ground up, then you will be able to design the DB and
make it nice and pretty. This is seldom the case in any case but web development.
This is simply hogwash. RDBMSs are by their nature
non-generic espoecially when one adds foreign keys and constaints to a system
which are necessary for any decent sized application. On the other hand the
entire point of object oriented programming is creating generic reusable
components. With the ability to use inheritance and polymorphism in an ODBMS I
see no reason why you believe an RDBMS is more generic.
'Generic' may be the wrong word here. A better one would be 'simpler'. A lot of applications
just don't need all the OO stuff. The reason that RDBMSs are so pervasive is
because most data can be represented well and in an easy to understand way with
just tables and keys.
Learning
OODBMS techniques is mainly learning how to use another API in your bject
Oriented programming language of choice (well C++, Java or Smalltalk) versus
learning SQL and relational database theory. If people could learn SQL which is
completely unrelated to any other aspect of their programming experience then
adding OODBMS techniques as a skillset would be trivial. Of course, if people
don't realize that alternatives to RDBMSs exist then they won't learn these
techniques. That is more important because management can't find people who have
these skills if developers don't go out and learn these techniques.
Developers aren't the only ones who have to query the database. In my shop,
we have 10-20 people querying the same database. Many of whom have spent a lot
of time learning SQL. Most of the people who need to look at the data are
not able to pick up a new query language quickly enough. SQL is simple
enough to learn. RDBMSs are simple and easy to understand. With an OODBMS,
these people have to be trained on what the heck OO is. This is not an easy
concept for a non-progammer. On the other hand, tell someone that the database
is a collection of tables, and they can easily understand.
Now I just realized you didn't read the
article. People have measured gains in the range of ten to a thousandfold
increase in performance, these are not incremental. Secondly the primary benefit
is that it means you have to write less code and don't have to worry
about multiple paradigms at once when implementing an application.
Sure. I'll believe it when I see it. This sounds like marketing hype to me.
Sounds like someone who didn't know how to program for an RDBMS wrote some
crappy code. Correctly written code for an RDBMS would not experience these
kinds of gains when converted to an OODBMS. The overhead for the conversion
process could be this large, but only if the original code is crap.
Mad Software: Rantings on Developing So
Perhaps.... because Oracle isn't an OODBMS.
-- The act of censorship is always worse than whatever is being censored. Always.
On the occasions I've tried picking it up, I've usually ended up with headaches. Either in terms of how people think or how computers work, it makes no sense that I've ever been able to figure.
My most recent attempt was to pick up Visual C++ for an image-processing class I'm taking this semester (the instructor recommended it in order to access whatever bells and whistles Win32 offers). It seemed to me that you spent more time moving widgets around on the screen than you spent actually writing program code. After a few weeks, I said "screw this" and went back to gcc under Linux. While the rest of the class was running into trouble getting its software working (I'll admit that I don't know if they were struggling to get VC++ to do what they wanted or if they were running into more fundamental problems with the algorithms to be coded), I was producing working code for histogram equalization, 2-D Fourier transforms, and DCT-based lossy image compression (among other things) long before anyone else I spoke with on the subject.
20 January 2017: the End of an Error.
Apparently someone didn't get the reference to The Simpsons episode 4F12.
oh well. I should never try to be funny again.
Being a PHP coder I'd really love an OODBMS but then, amongst the few that exists, none of them can be interfaced with PHP. Most of them are geared at Java or C++ (which are much better OO languages than PHP) but then, that's not what many web developper use for their apps !
One interesting compromise is to use O/R mapping layers; you put all your data in a traditional SQL database and describe a mapping to objects.
A couple of interesting open-source ones are Castor and Osage. I haven't had the chance to use either one in a serious project yet, but as a NeXT refugee I'm looking forward to using a good O/R mapping layer again. Do people have any recommendations?
For those interested in the topic, there is useful information at Scott Ambler's site, including his white paper The Design of a Robust Persistence Layer for Relational Databases.
1. From the management perspective: RDBMS people are easier to find and there are more big iron Oracle installations that all OODBMS combined (my guess).
2. From the developer perspective: the overhead between of the OO layer on top of the database is known. What if I get a OODBMS with superb C++/Smalltalk integration but poor Java support?
There are certain design/implementation patterns that deal with OO/RDBMS impedance mismatch and the burden of reimplementing them for every project is accepted as a fact of life...
It has really spiffy Java Object Projection, and is a lot faster than Oracle.
http://www.e-dbms.com/
- - - - -
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
Cache solves some of the problems you point out. It's accessible relationally or via objects. New object interfaces can be added to existing ones, or to relational and non-relational data stores. So, Cache is generic. Complexity -- because Cache can also be accessed as a relational database, you can write a new Java OO app using its object interface and let older apps continue to use its SQL interface. Skills availability -- start relational, have the choice of trying OO.
- - - - -
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
http://www.e-dbms.com/cache/components/cacheobject s/index.html
- - - - -
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
I used to work for Excite@Home, in their E-Business Services unit (now defunct; those left are just an engineering adjunct to Excite@Home). We created a web-based store hosting product based entirely upon ObjectStore as the back-end using Java for dynamic page generation getting results from C++ query servers.
Unfortunately, the site became very popular, and with all the orders, order information, store products, etc. stored in the database, had hundreds of millions of objects (in some cases, very large objects) in the data store.
We began running up against the 32-bit barrier for address space within ObjectStore. At the time, there was no 64-bit version of ObjectStore (and I don't know if there is now). We would watch performance steadily degrade on our C++ queries over the course of 2 or 3 months, until finally it would nearly grind to a halt because of lack of address space and we would be forced into a 12-14 hour defragmentation routine. Each time we went through this cycle, it would start again, but performance would erode even faster.
Admittedly, we were doing some pretty bizarre stuff. ObjectStore didn't support on-the-fly schema changes, so we hacked some utilities which allowed us to do that (and which ate address space). We also stored all the product orders in the database, and we never fully deleted orders until we defragmented. But fundamentally, ObjectStore had a problem with scalability for extremely large databases (billions of objects).
We went to Oracle, and the problems disappeared. Hello, 64-bit world, hello nearly unlimited address space, bye-bye constant database defragmentation. I'm not saying Oracle is a panacea -- it's not, and is quirky as hell -- but it blew the crap out of ObjectStore in this case.
My two cents.
Matt Barnson
Matthew P. Barnson
I learn what I think when I read what I write
One thing is missing almost entirely in this thread:
The RDBMS people come up with examples like integrating large legacy databases, and working with OLAP tools etc. This is just one application domain. It's an important one, but not the only one.
There are a lot of situations where one wants to have persistence in a complex application. To get that by storing the data in an RDBMS seems to be less than desireable.
The point I want to make is that whether OODBMS or RDBMS or a combination of both is best is mainly dependent on the actual problem domain!
BTW: After reading all the problems people seem to have with their commercial OODBMS, I have an even better opinion about Zope's free ZODB. It has done a great job for me so far. With Zope's ZCatalog indexer you can solve a lot of the problems OO might bring.
My favorite OS isn't coded mostly in C. BeOS is almost completely C++.
Maybe you'll return to Minagua, You could go unnoticed in such a place. -FZ
OODBMS systems usually state different goal from RDBMS. The OODBMS goal is an persistentce for object. This is an cardinal break from RDMS parspective, which goal is to provide interface to structured persistence storage. Lets consider full typical stack of layers in RDBMS. 1. hard drive or other physical persistence staroage (disk/sector model) 2. file system above hard drive (folder/document model). 3. structre above files (database/table/record model). All three layers provide different interface to the bits on the dist but throw different concepts. They update disks on bits and start from bits on the disk. OODBMS-es do not start from bits on the disk, they start from objects an make them "persistent". The goal is unreachable. Object is transient thing and could not be made peristent. If you will kill a program and start it again you will have other object. OODBMS system usually invest to many efforts to maintain the Illusion of Persistence, but the Illusion is broken on every step. A schizophrenical double thought is required to program on OODBMS-es. Object is persistent and transient at the same time. It is especialy hard to think in this way in clustered environment. OODBMS-es will start to conquire the world when they will acknowledge reality of transient objects and persitent bits on the disk. So task will be good OO interfaces to those bits. Only OODBMS' innovation that worth trees killed in name of them is OID (and therefore an fast navigation) and which could be easily put in the RDBMS. I guess that SQL3 (or SQL99) already done it. Inheritance is really syntactic sugar over linking. Composition is also easy with oids and cascade on delete. "No Impedence Mismatch" cost loosing flexibility in schema changes. One data model is easily solved by automatic generation of interfaces from database, database scheme model just need to be enriched with binding info. But database should be an real source of data model.
OODBMS systems usually state different goal from RDBMS. The OODBMS goal is an persistentce for object. This is an cardinal break from RDMS parspective, which goal is to provide interface to structured persistence storage.
Lets consider full typical stack of layers in RDBMS.
All three layers provide different interface to the bits on the disk but throw different concepts. They update disks on bits and start from bits on the disk.
OODBMS-es do not start from bits on the disk, they start from objects an make them "persistent". The goal is unreachable. Object is transient thing and could not be made peristent. If you will kill a program and start it again you will have other object. OODBMS system usually invest to many efforts to maintain the Illusion of Persistence, but the Illusion is broken on every step. A schizophrenical double thought is required to program on OODBMS-es. Object is persistent and transient at the same time. It is especialy hard to think in this way in clustered environment.
OODBMS-es will start to conquire the world when they will acknowledge reality of transient objects and persitent bits on the disk. So task will be good OO interfaces to those bits.
Only OODBMS' innovation that worth trees killed in name of them is OID (and therefore an fast navigation) and which could be easily put in the RDBMS. I guess that SQL3 (or SQL99) already done it.
Inheritance is really syntactic sugar over linking.
Composition is also easy with oids and cascade on delete.
"No Impedence Mismatch" cost loosing flexibility in schema changes.
One data model is easily solved by automatic generation of interfaces from database, database scheme model just need to be enriched with binding info. But database should be an real source of data model.
One *huge* area that the article did not touch on is the lack of mathematical completeness in an OODBMS system.
When I join two tables in an RDBMS, a presice mathematical formula can be followed to join the tables with great effeciency (especially with the existence of keys).
Let's take an extremely simple example: I have a Company object that contains an array of People objects. The People object contains among it's attributes, a Last Name field.
I want to find all the Company's that employ 'Anderson's.
The join required in an RDBMS to do this is simple and effecient. How is this performed in an OODBMS? Is each company instantiated and it's People array walked, searching for 'Anderson'? Ick.
OODBMS has it's place, particularly in tree-based systems, where ad hoc queries are rare (cf. Zope's content management system), but RDBMS has a fundamental advantage when dealing with large data sets and/or joins.
I have used Versant on a medium to large scale development project. For 80-90% of the code, using and ODBMS was a dream. A simple persistant base class for objects which need to go in/out from the DB was an elegant solution that was a joy to use. I was all ready to become the new ODBMS advocate/zelot for all my future development projects.
Then I ran into a wall. The wall was Ad Hoc query. For most of our system, traversing an object model was a very elegant way of accessing data. But for that last 10%, we really needed a fast, efficient Ad Hoc query. Here is where the ODBMS fell flat on its face. The querys were slow, and doing something akin to a "join" was mighty painful. And of course, it turned out that these operations were the most used and the slowest part of our system. Everything came crashing down arround me. What had been a joy to develop, was a nightmare to use.
Our application was a series of seperate distributed apps, all reading and writing to a shared datastore. Although walking between related objects was a dream, finding the "head" of the tree would always be a PITA. Our data had a good parent-child-grandchild-etc has-a set of relationships. But finding the "interesting" parent objects was very, very slow. Once the parents were found, traversing thru the related data was fast and easy, but the startup of each operation was a huge bottleneck.
This may just be poor design experience on my and the other developer's parts. Just like a set of C developers can create a truly horrid C++ design, we RDBMS developers may have just abused the OODBMS. But the fact is we had a group of half a dozen experienced OO developers, and we all thought we had a good approach. If a group of developers with good OO programming experience, and good RDBMS experience can't figure out how to correctly use an ODBMS, then I don't have much hope for the technology. Either the technology has some serious limitations, or the learning curve is very, very steep. Either way, I've been sticking to my tried-and-true RDMBS every since.
Since the fine print on Oracle's million dollar offer DOESN'T include any of the OODBCs -- can we just assume that they recognize it's faster and more effecient, too?
---- Please be nice in case my Slashdot karma ~= my real life karma.
Just check out what google(tm) gives you for the search terms: object relational mapping.
yabba
I don't think the effect of vendor lock-in can be underestimated. Until there's a standard for accessing and bulk-loading/querying OODBMS like JDBC or ODBC, we're not going to see wide adoption of them for several reasons:
1) If your database isn't performing up to snuff, you can't switch to another vendor without re-writing tons of code.
2) If you need to integrate with another piece of software (ie. your company just bought another company and wants to incorporate that company's product into its own) you're out of luck.
3) If you have a large volume of legacy data you need to roll over into your system, loading it in and querying it will be a painful exercise.
We have a home-grown OODBMS-ish system at my company that we have to build our systems on and consequently it is very painful to integrate with anything from the outside world.
Programming is not a religion A hobby,job,profession,craft,art. But not a religion
This really means nothing to me, and here is why. If I were to even consider an OODBMS, it would have to be Open Source AND accessible from C++, Java, Perl, Python, you name it. Every where I look, just about every OODBMS is Java Java Java Java Java. Well, hello? The world isn't all about Java. I do plenty of work in Java, but I can't sacrifice support for other languages. I don't see any open source solutions that cross the language boundary.
Not really, you should be able to figure it out with a variation of the first java example (In the language of your choice, of course).
Once you have the hash table of objects, you should be able to print them out and then be able to work with them.
Its been my experience that data exists before the app does. In fact, its because that data exists that people want apps. The first step is to record the data and this can be done immediately by shoving it into a database.
Perhaps I could see using an OODBMS for optimization from an exisiting system, but these days optimization is often much easier by throwing more hardware at the problem.
t
Database schema changes aren't a problem with versioned databases and reflection. If you're a proceedural programmer, this is a huge twist on reality. Some DBAs just can't handle this kind of world and their heads explode because it just doesn't compute. Normalized data sets are _no longer required_. It takes a while to chew on and digest, but I can't say as they're all that bad. -sc
-- Sean Chittenden
6. The world is not object oriented. Even if oo is a usefull tool, it is no silver bullet.
Which makes more sense when writing an application using an object oriented programming language to develop an application? Using a database that is consistent with the programming paradigm and performs database operations transparently or one that requires the developer to go through additional hoops to get data, is generally slower, and involves writing more code?
7. RDBMS are proven technology and rather well standardised, OODBMS aren't. Currently there is a proposal for a standard (java data objects), but even that only addresses one plattform.
Not only is there a standard but the ODMG standard is on version 3, JDO is merely a Java standard. Please know the facts before flaming.
--
Hi, thanks for the responses, I didn't think anyone would be done reading it so quickly. :)
...and in an OO system some changes can be made without no effects on the existing applications. In the general case though an RDBMS is more flexible than an ODBMS.
Complexity. These systems are much more difficult to design than RDBMS. The application must be designed first, then the data structures must accomodate that. This kind of design is very expensive.
Aren't you supposed to design an application before implemnting it in any way including putting data in a DB? I've worked at two companies and had a ton of projects in school and none involved implemnting the database before the application was designed.
RDBMSs are generic. Since an OO system is designed for a specific application, it's difficult to use that system for anything else. A well-designed, properly normalized RDBMS can be used for many different applications. When a DB is going to fill many terabytes, you don't want to have multiple copies of it for each distinct reporting application.
This is simply hogwash. RDBMSs are by their nature non-generic espoecially when one adds foreign keys and constaints to a system which are necessary for any decent sized application. On the other hand the entire point of object oriented programming is creating generic reusable components. With the ability to use inheritance and polymorphism in an ODBMS I see no reason why you believe an RDBMS is more generic.
Schema changes. As mentioned in the article, schema changes are a nightmare with an OO system. In a relational system, some changes can be made with no impact on existing applications. Others are relatively uncomplicated compared to similar OO changes.
Skills availability. Yes, the old management problem. Everyone knows SQL; nobody knows OO.
Learning OODBMS techniques is mainly learning how to use another API in your bject Oriented programming language of choice (well C++, Java or Smalltalk) versus learning SQL and relational database theory. If people could learn SQL which is completely unrelated to any other aspect of their programming experience then adding OODBMS techniques as a skillset would be trivial. Of course, if people don't realize that alternatives to RDBMSs exist then they won't learn these techniques. That is more important because management can't find people who have these skills if developers don't go out and learn these techniques.
It's just not worth it. Given the dramatically higher costs associated with designing and maintaining an OO system, most applications just don't need the incremental performance gains associated with it. Very specialized, very high performance systems would benefit, but smaller or more general systems would not.
Now I just realized you didn't read the article. People have measured gains in the range of ten to a thousandfold increase in performance, these are not incremental. Secondly the primary benefit is that it means you have to write less code and don't have to worry about multiple paradigms at once when implementing an application.
Finally, where the heck are you getting this BS that designing an application with a single data model (i.e. one set of UML diagrams) is more expensive than designing one with 2 data models (i.e. an ER model for the DB, UML for the application).
--
that abstraction exists to decouple the application from the processor. plus the abstraction makes the code easier and quicker to write, debug, and maintain.
An RDBMS wouldn't have necessarily made reporting any easier. The sort of highly-normalized RDBMS schema that is appropriate for an OLTP-type application is quite hard to report against - data in such a schema isn't usually very "tabular", either.
Many shops that use an RDBMS for their OLTP systems end up building a seperate data warehouse with a flatter, more tabular schema that can be more easily queried for report generation.
This approach had the same advantages and disadvantages of an "object oriented database". The data was too closely coupled to the applications. Adding a new field or index required modifying and recompiling all the applications and rebuilding the database.
The great advantage of a relational DBMS in a business environment is that it isn't closely coupled to the applications. For long-lived data, this is essential. That's why relational DBMS systems won out over explicitly-linked databases decades ago. They have the flexibility needed for long-term data storage.
Persistent data storage of language objects is an idea that keeps recurring in academia. It can certainly be done, but the long-term operational headaches aren't worth the short-term gain.
A related problem is the storage of data trees in databases. The current buzzword for this is XML databases, but systems for this go back a long way; check out MUMPS. You can store a tree in a relational DBMS by breaking up all the nodes into rows and using serial numbers to tie them together, but retrieval takes a huge number of lookups. You can also store a tree as a BLOB (a binary object that the database system doesn't parse), but then you can't search it. There's no general agreement on how to approach this problem yet, but this, not persistent object storage, is probably the way to go.
The database community learned painfully to separate indexing from structure. In SQL, you can do any search regardless of whether indices exist to make it fast. Indexing is a performance enhancement, and indices can be created later as needed to improve performance, without impacting programs. Any new database system should have that property.
But you can't, for example, add two "Integer"s using plus operator... You have to convert back to primitive "int" type.
Donate free food to the hungry at The Hunger site.
On the topic of reliability, what about advanced DB features such as replication? Can I have ADSM log into the database and do a hot backup?
Of course then you have the age old issue of a company saying "We run DB2. Period." Then choosing an OO DB is a moot point...
Just to append it to the list in the article. I interned at an insurance company which is using IBM's VisualAge for Smalltalk and GemStone/S to run all of their insurance production definition. Really interesting stuff, actually. Define it in a GUI, and gen code for the mainframe.
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
I was going to cp that attachment code for java to an OODBMS here, but the preview button told me it was "Junk character post"
So imagine it is here.
Shell script for attaching to a user: sqlplus -s EOD scott/tiger EOD
Oracle and unix guy.
Where can I get a cheap/free OODMS?
Then from the "cheap OODMS" subset, what are the OODMS which have interfaces with Python/Ruby/other scripting language?
If the result is zero, then maybe that's one answer to "Why aren't you using an OODMS?".
Of course there are other things to "constrain" the query on like docs, examples, mailing lists.
Cheerio,
Link.
I've got a better question: why aren't you using the RDBMS?
Many of us who crow about the wonders of OO programming environments, don't have a firm grasp of the alternatives, nor do we fully appreciate the problems that those OO environments solve versus the good things they traded away. For building significant, long-lived, scalable, evolveable, administerable, restartable information systems the RDBMS has not been beat.
If we start from the opposite side, i.e. we start with the RDBMS and ask: what is it that is distasteful about programming in this environment, we might actually get somewhere. If I take Oracle as an example and compare it to e.g. Java the only shortcoming I see with Oracle's PL/SQL is that it doesn't (to my knowledge) support polymorphism. It does support encapsulation and abstraction (functions, procedures, packages with data hiding), and the biggie: declarative, optimizable association specification. It certainly supports "structured programming". Are you willing to trade away all that RDBMS goodness just to get polymorphism. Seems like a poor tradeoff.
I'll go even further. It is not at all obvious that the OO "model" is superior to the relational one. These observations from this paper by McCarthy apply just as well now to OO models, as they did to non-relational (accounting) models back in 1982 (pp 554-555):
(2) Its classification schemes are not always appropriate. The chart of accounts for a particular enterprise represents all of the categories into which information concerning economic affairs may be placed. This will often lead to data being left out or classified in a manner that hides its nature from non-accountants.
(3) Its aggregation level for stored information is too high. Accounting data is used by a wide variety of decision makers, each needing differing amounts of quantity, aggregation, and focus depending upon their personalities, decision styles, and conceptual structures. Therefore information concerning economic events and objects should be kept in as elementary a form as possible to be aggregated by the eventual user.
What McCarthy is arguing for is dis-encapsulation! Anti-OO. I think there's an important lesson there.
So the question is: can we have that flexibility along with maintainability?
Also, be careful to avoid reasoning from an outdated view of the data type expressiveness offered by the modern RDBMS. All the major vendors are now offering so-called OO/Relational features such as object identifiers, large objects, arrays, structures, sub-tables.
IMO, extended-relational has the best chance at success because at its core you have the solid relational mathematics developed by Codd so many years ago (a solid starting point). But has anybody used the OO features of Oracle 8i for instance. I have, and I thought it sucked. It seemed all they did was put an OO interface on relational tables. You could still access OO data via standard SQL so you couldn't guarantee encapsulation, etc. and all the other great promises of the OO paradigm.
I've also used O2. Very interesting appproach, but hardly solid. (and as I've mentioned, they've gone out of business) Each vendor builds the quailties of an OO database they feel are necessary and there is no consistancy among vendors (as in the RDB world). Products are either significantly immature, lack serious qualities required for a production DBMS, or just plain don't work. (Note: I don't necessarily think this is a bad approach to the design of an OODB, in that I felt these types of products preserved a lot of what OO was trying to do. Its just that nobody has been able to define an concise, solid theory (like the relational model) upon which to build these products)
So to answer the question, why don't I use a OODBMS? Simply because the technology isn't superior to my existing RDB yet. Only in certain niche solutions (engineering, BOM's, etc.) might I actually consider using such a product. I feel its a straight-forward example of right tool for the right job.
-- A computer without COBOL and Fortran is like a piece of chocolate cake without ketchup and mustard
We've looked at OODMS's a few times over the last couple of years.
The things I considered were,
1) Most programmers that worth with databases understand relational databases. They are less likely to write "database-killing" code that will bring the server to it's knees.
2) How much do you gain by removing the object-relational mapping that you have to do when doing Java/C++ --> Oracle/DB2? That mapping can sometimes be a pain, especially when doing many-to-many relationships. In addition, SQL code in Java is not compile-time checked if you use Statements/Prepared statements. An Object Oriented DBMS should give you compile time checking.
3) What type of data are you putting on this database? Mission critical? What sort of support does the vendor provide, and can you count on the vendor to be there in five years?
4) What sort of tools are available for designing the schema? The schema is the foundation for a database-driven application. Change the schema, and you can screw up alot of code that relies on the schema.
I'm all for OODBMS's. But while they are in their infancy, you can't bet the farm on them
We've looked at OODMS's a few times over the last couple of years.
The things I considered were,
1) Most programmers that worth with databases understand relational databases. They are less likely to write "database-killing" code that will bring the server to it's knees.
2) How much do you gain by removing the object-relational mapping that you have to do when doing Java/C++ --> Oracle/DB2? That mapping can sometimes be a pain, especially when doing many-to-many relationships. In addition, SQL code in Java is not compile-time checked if you use Statements/Prepared statements. An Object Oriented DBMS should give you compile time checking.
3) What type of data are you putting on this database? Mission critical? What sort of support does the vendor provide, and can you count on the vendor to be there in five years?
4) What sort of tools are available for designing the schema? The schema is the foundation for a database-driven application. Change the schema, and you can screw up alot of code that relies on the schema.
I'm all for OODBMS's. But while they are in their infancy, you can't bet the farm on them.
SAL has listings of a bunch of OODBs.
Don't system designs using UML or any modelling technique used today translate quite simply to an OODB, since they are OO to start with?
The application must be designed first...of course, on successful projects people don't immediately start coding without knowing what they're coding. I don't see how that differs depending on an RDB or OODB world...
Isn't that like saying you can't use the RDB you designed for project A on project B? It seems to me if you can move tables representing objects from project A to project B, you should be able to move the objects from the OODB used in project A to project B. The transportability of the objects OR tables depends on the relationship/similarity between the two projects.
I don't understand what you mean by multiple copies of an multi terabyte OODB....
If changes can be made to the RDB tables without impacting the system, can't correspondingly similar changes be made to the OODB object models? If code has to change in one, it would seem to me that code would have to change in the other.
Can't argue with that. Reminds me of a quote from a book that went something like this: "Like it or not, SQL is intergalactic interspeak."
As I said, I'm not very familiar with either, and any clarification of your points would be appreciated.
I think you should warn modem users (or other low-bandwidth surfers) that this page, with its long story and probably 200-300 comments by tonight, is one that they should stay away from!
If you celebrate Xmas, befriend me (538
Its an impedence mismatch to development, however who is to say that Objects are as good on disk represenation of data as they are in memory?
For object databases I've only tried Versant and it had a java interface that looked like C. It gave this tantalizing view of how productive OODBMS could be but kept it just out of reach
Please note that productive doesn't equal performant. Object databases score when you have many complex inter-object relationships, and you're not sure which relationships you are going traverse at run time. They suck for things like reporting - where you access the same data in many different ways - suddenly what was a single query in RDBMS world becomes a set of linking methods and indexing objects. More flexible but more time.
Special Relativity: The person in the other queue thinks yours is moving faster.
I work at a large telecommunications company and I work on a very large (understatement) database with billions of records loaded daily. We employ the eXtreme Programming model for development. Our database is a release database and we modify it weekly. Adding new features, tables. Changing things as we go. As long as we control the interface changes are 'cheap' in cost. I shudder to think of how all these changes would be under an OO database. If you plan on using an OO database, you are basically cut out of the xprogramming style. You spend MUCH more time in 'designing' and less time 'delivering'. Thanks, but no thanks.
I went on to work at a job involving a similar product, which stored data persistently in a Poet OODB. Although the basic functionality of Poet seemed to work correctly, my manager had chosen Poet in order to use a special feature that had been advertised, but (as it turns out) wasn't completed at the time the DB was released. Support e-mails turned into intercontinental discussions with the German developers of the product, weeks turned into months, and before long this project was a year behind schedule, due almost solely to a dependence on an OODB. Finally, Poet modified their licensing scheme (forcing potential users of our project to absorb exorbitant sub-licensing fees), and that broke the back of the whole effort.
I moved on to a new job at a large information services company. Here, they've been using Objectivity internally for some years, but we're now in the process of converting over to Oracle. Problems with scalability, with bugs, with support, and with licensing has driven the company to look for alternatives.
In short, I have no arguments against the underlying technology of OODBMSs, but I have yet to find an OODB company that can execute well enough to make their product worthwhile.
--John
The idea of OODBMS sounds great - on paper. I have experience managing two large-scale systems that used OODB's over the past 3 years.
The issues I ran into were lack maintainability and flexability. Geeze, aren't those the things you really WANT in a database?
While an overpriced "explorer" type tool was available for browsing the database, there are no ad-hoc query tools. An application has to be written to work with the data. This also eliminates the ability of DBA's to manually look into the system, and optionally massage the data.
You also have to keep in mind that the corporate world is very row / column oriented, and random blobs of data are useless. While some OODMS's have ODBC interfaces, they are difficult to work with and generally provide for an incomplete mapping (unless you design your objects as row / column like, and then why use an OODBMS?)
The other big issue with OODBMS's in general is that they push processing off to the client. The server basically delievers "memory pages", and the client does all the processing. This causes increased network utilization, and requires that the clients have massive horsepower (this is the opposite of the popular thin-client approach.)
Other random comments:
The inability to make schema changes without rebuilding applications is a BIG DEAL and is one of the KEY reasons that OODB's suck. Now you are talking about major deployment issues, increased downtime, etc.
Doing simple SQL queries can be a TON of code on an OODBMS. With SQL, you spend time coding getting data to and from the DB, and with OODB you spend time coding what the (well-tested and robust) RDBMS was doing on the server. It's quite obvious which one has a higher chance of having bugs.
As for "who is using OODB", how about the Massive list of those that are NOT? Ah. Not enough paper in the printer for that list...
So in my own conclusion, I'll conceed that there are gains in "developing" with an OODB in an OO language, but in the "real" world, we don't just develop. We USE. It's the "using" part that fails with an OODB. The inability to interact without a specialized app for each and every little thing you may want to do is a showstopper. You end up having to recreate your toolset for each project, and can't leverage generalized commercial tools. You also limit yourself to not being able to integrate with other applications that do use RDBMS's in your enterprise (and there are LOTS of those...) This gets WAY expensive folks...
Well, I was involved for a while in a project that used an OODBMS. O2 in fact -- a product that was, last I looked, discontinued.
/not/ be confused with SQL datbases. They are not implimented in anything like the same way. And they have a very different set of costs.
Problems with OODBMS
1. OQL implemations
2. dont' share data so well because most
are file-based implementations NOT servers
3. schema
4. administration
O2 worked, but the schema issue turned into a problem. Same sort of thing as versioning interfaces in CORBA. Every time an object is changed, Phoof.
OQL implementations are not particularly well done. Some systems do, some don't. And the variation in these is wide.
Administrative tools for a application on the OODBMS we used had to be written as part of the project. Reporting out of a OODBMS data set of course needs you to write more code. You cannot just use a copy of Access or similar.
You do not have a tidy client-server relationship across the wire in most of the products I checked out. There was one, but it cost $50,000. so you have to host the OODBMS on the same server as the application. Unless you care to get into CORBA or other 3rd party wire protocol.
Oh, and there are few 3rd party tools around for them.
OODBMS really must
My 1/2 penny worth.
Way back when, I worked on a new-fangled air-defense system that was going to be 100% high level language - no assembly language for us, no-siree! The machine was state of the art - 16 mhz with 24 terminals hung off it - power to burn! Fortunately, my boss had the sense to write a small snippet of code that pretended to be a radar feeding a control program - classic client-server code. No real radar processing was involved and the control program didn't have to do anything with the fake return except count it. Our design spec called for handling 2000 returns per minute. The simple client-server code he wrote could only manage 500 returns/minute. Fortunately, the test happened early in the coding phase so we were able to re-design portions of the system to adjust to the physical realities of the hardware.
Abstraction is nice but be sure it's not so abstract that the hardware can't handle it.
As patchy as the SQL, ODBC, and JDBC standards may be, they have commoditized the DBMS market. Until object databases can do the same (the ODMG standards don't even come close), they lock you into a proprietary solution. Ultimately, if your database doesn't scale as well as you'd like, that will hurt performance.
OODBMS's promised to be the holy grail... a revolution as big as relational algebra for the database realm... current implementations of OODBMS's have certain diffieciencies(sp?)... from what I've seen these diffieciencies may soon be solved... but a major drawback is the loss of the set at a time data manipulation capability that can be had in RDBMS's... that could be due to the way we view OODBMS's or maybe the fact we don't yet have a language that properly defines all the data manipulation and/or data definition. There was recently some research I read done by a grad student at the University of Alberta in Edmonton... it was his disseratation actually... in it he defines a "type system for an object oriented database programming language" link can be had here: http://www.ualberta.ca/ExpressNews/news/2001/02140 1.htm
his personal webpage here along with the link to his dissertation:
http://web.cs.ualberta.ca/~yuri/
It is a 247 page disseratation so if you thought the parent article was long... then you probably don't want to tackle this... but it is quite interesting...
addbo
At work I use a system that sends financial transactions over an IP connection, writing them to an RDBMS. Depending upon the configuration this consists of between 3 and 5 processes per environment. Each process consumes a minimum of 6MB. but I've seen processes of 400MB in size, caused by handling a modest number of transactions. Everything is coded in C++.
10 years ago, the entire system would probably run as fast on a machine with a total of 6MB of RAM. Progress?
Sorry, but I've never been convinced by OOP. There is too much abstraction between the source code and the processor.
As I have seen mentioned "Nobody gets fired for using Oracle" and I have yet to seen anything that will run faster than Oracle. Honestly if you have the money, I can't see a reson not to go with Oracle. It's fast, it will scale, and you can find talent to help you tune it.
At my job we use WebObjects to go the OO route. This is NeXT technology that Apple bought. One of WebObjects features that is very nice is EnterpriseObjects. I can suck in an existing database schema or create my own in eomodel and all my table become objects that I can use. Granted there is a layer between my code and the database, but I never put a line of SQL in my code. Usually all I do is make calls to accessor methods to get or modify the EnterpriseObject which is the data from the db.
This is something our DBA thinks is a slighty bad thing. If I have data in 2 seperate DBs, I can use eomodel to connect that data up and display it to the user. The really cool part to this is that they don't even have to be the same kind of db. You can mix data from Oracle with DB2 or SQL server. With a database abstraction layer this powerful why should I be using a OODBMS when I've yet to see them have the same performance of a powerful RDBMS like Oracle?
Brought to you by Team SPAM! where we believe: "Information in the noise!"
To abuse an old quote: "No one ever got fired for buying a database from Oracle."
I used to work for one of the OODBMS firms mentioned, and a lot of our customers at that time were universities and a few companies doing small pilot projects with the database. But if you're an IT manager doing a serious database project, which vendor are you going to choose: a multi-billion dollar company like Oracle, or a relatively tiny OODBMS vendor that might not be around in a few years?
This piece sounds more like an ad than a real research paper. There aren't any real numbers, just the assertion that an OODMS can be faster on complex datatypes than an RDBMS. In what *specific* cases is an object-oriented database faster ? Then there's the "statisfied customer" section, "All these people are using object-oriented databases..."
The code size comparison is pretty useless. The code I use with Apple's EOF is more compact than any example here, and it can accomodate any kind of DB.
I'm sure that there are times when using an OODMS is a good choice. This article does nothing to help me determine what those times are.While "object" math could get there, it hasn't yet. And, since we're all angelic coders who wouldn't think of deploying software that we hadn't proved computationally correct, how do we prove computational correctness of OO-data?
At least with relational-OO "mapping" we can prove that what we lose in the mapping is inconsequential to the application at hand.
Personally, I think we've evolved beyond it, although it does work well "on paper". :-)
One of the issues I've argued with OODBMS vendors is how to do ad-hoc queries. Some of them provide SQL interfaces to let you access the OO database, meaning they're mirroring their OO structure with a relational structure - but the query responsiveness always bites. Just don't try to do complex joins - they ain't worth the effort (yet).
As for reusing the database - if you have access to the object model, you can reuse the database - and each vendor has their own ways to make different parts visible to different applications.
I love vegetarians - some of my favorite foods are vegetarians.
It's obvious from reading the majority of responses why there are so few OODBMSes installed and running: ignorance. Comments such as unproven and untested ignore even the attached article about successful terabyte OODBMSes running at CERN in Switzerland on Objectivity, not to mention several enterprise-wide installations at OOCL, several major financial institutions and a whole bunch of others. Just check out Brocat's webpage for a list of GemStone users. The lack of third-party reporting tools aren't terribly important if you consider that writing code to access your database can be done inside a running environment on live data. Your development environment (eg, IBM's VisualAge Smalltalk or Cincom's VisualWorks Smalltalk) gives developers the ability to access their objects. Your manager wants a prettified report? Build a reporting system. Stop being so lazy! :)
I'm amazed that no-one has written in saying that they've worked on a successful OO database. They've been around (in GemStone's case, again) for 15 years and are hardly new.
"He treats objects like women, man!"
- The Dude, The Big Lebowski
From my point of view, there is an additional reason.
Theoretical rudiments for relational databases do exist and are well understood by some. I am not referring to SQL here, but rather to math.
Term 'relation' is well defined. Math behind it is pretty and simple. Simple is good.
So, on the one side we have well defined mathematical concept that can be worked on. On the other hand - elusive 'art of objects'. Although I personally prefer the latter (makes me feel good about myself) I always appreciate ability to define software in more solid terms. A relational database engine (what it does, what it needs to do) can be defined in terms of quite comprehensible algebra.
There are similar efforts for OODBMS (evolving algebras, for instance) but these are relatively recent - and most people doesn't care about them.
Conclusion: relational database engines are simple in construction. OO databases are not. Simple is good. Complex is bad. Long live RDBMS.
-m-
I would like to die like my grandfather did - sleeping. And not screaming in terror, like his passengers.
[Insert snide comment here] Take a look at that pinnacle of Object Oriented Programming, Microsoft Office
That cheap shot aside, The ramp up to a level of truly competent understanding is much longer than anticipated. The problem is that often OOP can give the appearance of competancy to those not in the know, but you still have the same problems that you had before, that can be much more difficult to find, if you are not expert
Check out the Vinny the Vampire comic strip
"It is a greater offense to steal men's labor, than their clothes"
By way of introduction, I was a Booch disciple in the 80s who learned the hard way the limits of OOD. Nowadays I'm a database architect working in UDB, Oracle and PostgreSQL, basically because that is what people pay for, not because I have an ideological bias. There are several reasons why almost everybody who has studied the issue picked RDMBSs: Speed - there is no way you can interact with an object store within an order of magnitude of the speed of an RDBMS query. The extra runtime checking and specialized data types slow you down. You might fix the second factor by having standard, simple data types, but that puts you back in relational territory. Query capability - almost all data intensive applications work on large sets of data; OO has real trouble working above the level of a single instantiation. Imagine how you would say "total all invoice line items for part number 9999 and subtotal by region" in your favorite OOP environment and you'll see what I mean. What I came to understand about OO is that while it can be applied to any problem domain, its practical problem domain is making programmers more effective. Now this is a practical, not theoretical limitation; at some point someone will invent a DBMS that is an RDBMS and an ODBMS (no, I'm not talking about Object-Relational DBMSs), and we'll all be happy. Oracle is drifting in that direction, and sonner or later they'll get there. Now, there are database problem domains that are good fits for ODBMSs. For example, sharing medical records across doctors' offices. No one office would have a lot of data, and privacy issues would make it unusual to query all the data at once. My experience, though, is that there are almost no database problem domains that work at the single instantiation level.
So if the tool/technology isnt popular, there arent enough people who are familiar with it. And OTOH, if there arent enough people familiar with it, the tool doesnt gain popularity :)
I don't think I've seen anybody ask the question. What if you used both OODBMS and RDBMS?
For the past couple years we at Kaivo have been working with Python and Zope. Typically we have been storing our data as objects in the ZODB (zope's object database). Also, recently we have been working with a company called Fresher who has just released a SQL Object Database called Matisse (http://www.matisse.com), which got it's roots in a French nuclear power plant some 12 years ago. We have the same struggles as everyone else. When should we store data in an object database, and when does it make sense to use something like Postgres?
Someone brought it to my attention that maybe object databases should be used as a middle tier storage platform, then the data could be pushed nightly (or weekly) to a relational database to be archived. Your application would access your current data in 'real time' directly from the object database cache, and could grab old data from the archived relational data.
--
Scott Robert Ladd
Master of Complexity
Destroyer of Order and Chaos
All about me
Now then, if you managed to find a language whose native types were *all* expressed as objects, where my data were all most naturally expressed as an object
Eiffel? C#? How about the originial -- Smalltalk.
(god bless Objective C and Scheme)
I don't know much about Objective C, but Scheme? In no sense are, for example, numbers treated like OOP objects in Scheme. I mean, you can't subclass them. They are objects in a non-OOP sense, I guess -- you can query their type and all. But this sense is irrelevant to the current thread.
did ya look at the list of examples on the page? i haven't used it's db at all, but supposibly zope contains an oodbms (among other listed above)..
If I understand correctly, the idea is that the RDBMS is turned into an object persistance store. You pull the object's data from the data store, manipulate the object (which may or may not update the database), and then you can store the object back away.
The idea seems to be that we should not abstract ("essentialize") database transactions. We shouldn't have to think about transactions with the data store, and by golly, we won't. We'll make the database a 1:1 mapping with the objects, and that'll be that.
It's a terrible idea. You want as tight control over your trips to the database as possible. Sure, if you're running a small app on one machine, you're fine. But if you've got hoards of transactions coming through, it is really important to watch those trips.
When I worked with WebObjects/EOF, us developers were constantly doing a tug and pull with the system, trying to get just the data we wanted. Different object sets and different APIs would have different ways of presenting the very simple information we needed.
For example, say I have 500K entries in the People table. We want to view their name and email, and a couple other things, 50 at a time.
With an object store, even though I only want their name and email, I've got to pull out everything else in there. What an incredible waste! There are so 10-20 fields in there!
In proper OO fashion, these folks are in a list. I can't possibly pull out 500K entries, so the API goes through twists and contortions to let me select out just the first 50, and then page through in 50.
Do you see what's happened? OO programming has "degraded" itself into what should be SQL land, though it's doing a damn poor job of it. Sure, it sounds nice to say, "Oh yeah, we'll just make an object in the OOP program an object in the database", but what happens when that object is a linked list of 500K items? Suddenly you have these lazy bindings from your linked lists, and each time you traverse another item in the list, it's making a query!
We had to have 5-7 test database servers so that we could make sure our performance was okay, every time we made a change!
Ug! What a terrible idea..!
We would have the friggen SQL written down, EXACTLY like we wanted, and it was terribly frustrating to have to wrestle with this system, trying to get our fucking data out, and nothing BUT our data out..! A lot of programmers just didn't bother. "We'll just pack in more RAM." Eeeee! The database guys hated us.
Is this project out in the wild yet?
:-)
I've been looking for a decent Linux genealogy app, the existing ones are all a bit crappy, and the projects for new ones are run by wanna-be's who only talk and don't actually achieve anything.
I've become so frustrated, I've started designing my own and have been pondering over the object/relational thing and language/toolkit issues.
If yours is any good, I might as well throw mine away, no use re-inventing the wheel
We write GBs of data application source in UNIX Shell calling Oracle PL/SQL. Thanks for promoting all the MVS JCL script kiddies to section head.
We insist on summing all details in a hierarchy before we report them via a CSV file delivered in email using nasty COURIER10 fonts, never mind that we could much more easily compute the few relevant intersections on-the-fly. Gee, thanks all you Finance analysts used to reams of paper reports from FORTRAN & COBOL!
We entrust programming and support to the most junior folks. Training consists of "Here, just go to these 1 week Oracle & HP courses, then work on your development plan with Sue. We'll make you a productive programmer in 3 months; look how well Sue is doing @ 8 months." Wow, thanks all you MBA and biz-school Luddites we promoted because you grovel so cheerfully!!
We only promote the best apple polishers to Systems "Boy", then only let them gather requirements using Microsoft's glorified "typewriter" and "calculator" from the dullest of clerks. The project plans neatly display the finest of Waterfall Development, complete with revisionist history to mask the 6 month delay...
We centralize all the technies into one padded cell so the line folks -- marketing & sales -- never be troubled by an occasional reality check: "So, why are mauve DBs more performant for capturing Zost market share? I'll need a more transparent explanation before I'm aligned." ...
We constantly strive to "get closer to the business", yet rarely point out that our systems ordered the materials, assembled the products, and collected the revenue so everyone's paycheck could be cut. Put an Easter Egg in a program? That's too individualistic!
And you want me to get an OODBMS in use? I've been fighting for FOUR YEARS to use Perl instead of those brain-dead UNIX scripts!
Zappy5000
Give a man a fish and he will eat for a day.
Give a man a fish and he will eat for a day.
Teach him to eat and he will fish forever.
I have used ZODB outside Zope. I'm writing, on the side, an application for managing genealogy through a GUI interface, and so far ZODB and wxPython have made the job a breeze. Already the app is fast, simple, easily deployed, reliable, scaleable, etc. etc.
:-)
In fact I wish I had seen this article sooner because ZODB and Python eliminate most of the complaints I've seen from everyone. I just hope someone sees this.
- Complexity: what complexity? To write RDBMS oriented software I have to write the schema and the application. With ZODB I only have to write the application.
- Generic: I haven't used other OODBMS but I see no evidence of a ZODB instance being constrained to use in a single application.
- Schema changes: Python deals so gracefully with changes to the application classes that in practice, it is rare to need to update the database to match the schema. Sometimes a "live update" trick is needed, but if you grep for "__setstate__" in the Zope source code (which has been evolving for years now) I think you'll find the need is quite rare.
- Skills availability: To the programmer, ZODB is but a thin layer above Python. Python is easy to learn and rapidly growing in popularity.
- Scaleability: ZODB includes a "BTrees" module which lets you fetch and store only the data you need.
- Object-Relational mapping: ZODB is certainly not perfect or universal. Some prefer to store their OO data in an RDBMS. ZODB has a layer of abstraction that lets you write an O/R mapping. Unfortunately no one has taken advantage of this yet, perhaps because the OO store is nearly always sufficient.
Now, I can see that an OODB would have major problems with more tightly constrained languages. Both C++ and Java would probably throw a fit if you tried to deserialize an object that was created with an older version of a class. But Python merrily lets you do it, and that makes all the difference IMHO.
Use Zope!
Not quite yet; I've been trying to come up with a good name. "FamilySource" is my current favorite.
Use Zope!
Because I'm too lazy to read 21846 bytes of text that explains why I should.
Here's another example for your case against OO: We implemented Poet, (at no small cost, I might add) only to find that within 6 months of beginning to use Poet as our major DB, a major 'Organizational Re-Adjustment' and a 'Data Center Consolidation' project wiped the whole dang thing in favor of DB2/OS390.
Now, our DB2 performance is actually much better than Poet ever was. Perhaps this is due to having highly skilled DB2 DBAs, or something. All the same, it is not worth going to a very expensive, single application db. Always use something standard, flexible, and easy to find admins for. It's worth it in the long run.
-WS
An operating system should be like a light switch... simple, effective, easy to use, and designed for everyone.
Of course, just because they're teaching Java doesn't neccessarily mean they're teaching OO. Java may force you to use the OO-buzzword "class" at least once in every program, but it is quite possible to write Java that ignores most of the principles of OO design.
where there's fish, there's cats
You know, there are classes that mirror the primitives, if thats really an issue.
I Browse at +4 Flamebait
Open Source Sysadmin
Is there a reason that Oracle wasn't in the list of OODBMS? It's only the most used database in the world...
And the reason I'm not using it yet is because it simply hasn't been around long enough. Oracle's implementation from what I understand is still a bit buggy. The RSBMS version has been around for muuch, much longer, and when you're dealing with enterprise-class applications, you sure as hell don't want to use anything that's even close to bleeding-edge.
This seems reason enough to me.
There's always sufficient, but not always at the right place nor for the right folks.
what the?
great comedy company.
Why is it that whenever a new tool is invented, some of its adherents insist on promoting it as the One True Way, damning all previous tools, and consigning these users to Outer Darkness(tm)?
Both OODBMS and RDBMS have their places. OODBMS is most appropriate when a specific application needs persistance. Because the schema is developed in concert with the application, it can be incredibly efficent. Imagine how you'd implement a linked list in and OO system, it looks almost identical to an in-memory version, which each node having a direct pointer to the one next in line. Using relational techniques here would imply that the 'link' portion of the node contained the primary key to the next node. Clearly not very efficient.
The RDBMS shines, however, in a more general environment, where all the uses for the data are not yet well known. As noted, columns and tables can be added easily, and ad hoc queries are no problem. The relational model has a well defined mathematical basis, that lends itself well to these generalities.
As many /.ers are fond of saying: Use an appropriate tool
for the job.
I work for an evil multinational financial institution that does a ton of OO-based, client-server (or shall I say, network computing) apps. We've looked at OODBMS from time to time and shied away from them as a vehicle for large corporate apps. The reasons:
PERFORMANCE: They just don't perform for high-volume, on-line, real-time situations. Period.
TOO CLOSE TO THE CODE: The structure and nature of OODBMS stores forces too much thought from the Developer's perspective (consider the impact of object deep copies). We prefer to keep a cleaner line between database design and code access.
VISIBILTY OF DATA: A golden rule of Data/Function placement to put the data in a place (logical and physical) where it has the most visibility to its users and potential users. Fact is, it's tough to put an OODBMS on a boring old S/390 box - and I haven't seen a Unix or NT cluster that can take its place (even if they can house an OODBMS).
FUTURE APP USES: If I implement an OO app that uses an OODBMS, I know it works today. But the next app that comes along and needs to access that data may not be OO and may not be able to access the data.
OBJECT FIDELITY: Dumb problem.... but if the objects I store atrophy (i.e. the classes from which they're derived change), then I have a versioning problem. Sure there are ways to mitigate this problem through sound design, careful mgmt, etc. - but it's more crap to worry about.
Bottom-line for this kind of corporate computing environment is that OODBMS is a problematic technology. It forces too much up-front code design and doesn't provide enough long-term flexibility.
Ok... now tell me where I'm wrong (and you're probably right).
CrazyLegs
"Pork!!" said the Fish, and we all laughed.
Hey Rob, could you not post such code heavy topics on a Friday? I'm still caffeine deficient, burnt from the week, and I'd like a lighter, funnier /. to get me in the weekend mood. Save this stuff for Monday, and put up some Katz or Star Wars stuff.
Here we go again. Its OO therefor it must be better. Wrong. OO is something created for people to understand code-data relationships better, at the machine code level nothing changes. If the data makes more sense in a relational format then leave it that way, don't shoehorn it into an OO format simply because OO is currently flavour of the month. Also OO databases are non generic. Fine if you're only going to use the database for 1 thing but in the real world you may have dozens of apps accessing the same data in different ways. Forcing every application to use the same class models regardless of their needs is a stupid idea. In the real world applications are written in a way to get a job done as fast and efficiently as possible, NOT in a way that would look cool in some ivory tower acedemics OO text book.
On the subject of whether one should design the application or the database first:
Check out PHPMyEdit. You can design the database first and then use PHPMyEdit to generate the code for the application. I'm not saying that in every case you should design the database first - I'm just pointing out that in this particular case, you would definitely want to design the database first. Of course, PHPMyEdit might not give you exactly the application you want, but it's good for prototyping.
sig: BeanShell: lightweight scripting for Ja
I claim this is false.
If you want me to believe it you're going to have to supply some data to back it up.
But ignoring that for the moment, (after all there are some people out there trying to use OO and RDBM) maybe it's the choice of OO as the programming language that should be changed, not the database.
The simple fact that the paper does not even mention this possibility makes me very skeptical of it.
It may come as a shock to you, but many of us do not accept that encapsulation, polymorphism and inheritance are necessarily good things, and aren't real keen on having them forced upon us by a database system.
Having worked for a number of companies, I can say from experience that the hardest part of the problem isn't processing the data, but obtaining it.
The key is whether RDMS is better for the people who input the data.
These are the people who count.
A good programmer will do his job once. Data entry will continue for many years to come.
Worrying about the language, or claiming that it's going to have a major impact on a project is like worrying about the brand of wax your mechanic uses for detailing. Sure, it matters, but there are other things that are far more important.
Well, because most of [pick your favorite open source piece of shit] was designed piecemeal, with no real goal in mind. Developers with no deadlines or specs wrote things as they came, and the fact is that it is much easier and quicker to ignore things like data integrity, pluggability or thread safety. C++ is a much more elegant weapon, and you'll find that a vast majority of corporate software is written in C++. It's just easier when you're dealing with a massive project to design things OO (and no, i'm not a disciple of Rational), and from a maintnenace standpoint much easier to build enhancements or scrap old parts. You want to use a new graphics driver with different variable types (maybe going from ints to doubles)? Well, you don't have to worry about checking all your plugin code to be sure you're not removing a variable that's read by some piece of hacked code in C written by an amateur who thought he was speeding things up in his app. Because for all of the nobility of Open Source, it's much more difficult to check the source code of a dozen components using your FILESIZE variable to be sure that they're synchronized than it is to just utilize a synchronized getFilesize() method.
And of course, in the modern world of multiple servers and multiple tiers of service, OODMSs make a lot of sense. Rather than having to worry about locks and commits and dirty reads, you just offer all callers synchronized setXxX() methods and asynchronous getYyY() functions. Rather than have to worry about the schema when upgrading a product (and no, you don't always have to have a spec when you do this...i haven't seen a spec in months other than a few lines in an email) and worry about messing up older areas of an application which might use your fields differently, you can just alter the internal workings of the storage and leave the methods with the same output as before. To be honest, we do this kind of work in RDBMS systems already -- we use triggers to perform integrity checks and update related tables, indexes to speed up queries, stored procedures to perform reads and writes as if the db was an object, and most telling of all we use Views to hide the true nature of a DB.
Finally, OO is no more closed or proprietary than C code...in fact, it's much better. I can find out the source and methods of any java class in our company in seconds, and get detailed information on how they run thx. to javadoc. I don't need to hutn for annotated source code or wait on a post to alt.software.shitty.opensource.operatingsystems. Sure, they can be black boxes, but they should be...you don't want to fuck up the variables hidden in those boxes and you don't want to rely on them because they are inefficient.
Hey freaks: now you're ju
Fundamentally data and behaviour should not be coupled. Decoupling gives the most flexibility, but of course there is a cost. Objects are about behaviour. Data are about state. Multiple behaviours can be layed over the same state and most of does. This is a fundamental division that makes everything messy, but in the end it's there a must be accomidated.
But it's a big one. A company I worked for recently employed a RogueWave product to emulate an OODBMS on top of an relational DB, and the result was utter horror. Having to recompile everything as the result of a schema change is a major pain, especially if you have to deal with multiple versions of the codebase. Of course, the situation was worsened in this case because the RW software had to generate all of the mapping code.
I also find that building entity-relation models for relational DBs -- that is, thinking of objects in the form of tables, rows, and columns -- is a very clear way to figure out the problem domain and evaluate different solutions. A successful development process might well include a preliminary stage working with an RDBMS, even if only in working out the conceptual kinks, and then move on to an OODMS.
Finally, a crucial criterion I would employ in which system to go with is the complexity of the data to be stored. The application I worked with was a horrible candidate for an OODBMS because the information itself was simple: names, contact info, and the like, which fits the relational model quite naturally. On the other hand, I'm about to start on a project of my own utilizing highly complex objects, capable of much greater sophistication than in my other example. I will most likely use an OODBMS, for instance db40.
1. It is not easier: I can provide examples of the same application in OODBMS and RDBMS and the OOP version takes almost twice as much code. 2. Your examples of corporate use of OODBMS: The revenues of the entire OODBMS industry is less than the advertising budget of any one of the major RDBMS vendors. 3. You don't need a query language: Yeah, the system just knows what you want and it jumps out. OODBMS are NOT: easier to implement easier to maintain easier to understand cheaper faster better in any way O.K. They taught you OOP in college. Now you can't think any other way. That doesn't make it better.
Isn't this tying too much of the DB design into the application? And it pretty much precludes reusing a DB unless you have access to the source code, doesn't it?
Linux *is* user friendly. It's not idiot-friendly or fool-friendly!
In fact, none of the open source implementations mentioned even comes close. Ozone, XL2, and Zope are quite language specific and don't even have C++ bindings. (There is a free OODBMs for C++, the Texas Persistent Store, but I think it also has many limitations.) FramerD isn't even an OODBMS because it doesn't attempt to bind language objects to database objects but introduces its own data model.
More generally, I think the traditional OODBMS approach turns out to be too rigid and too low level for many applications. If someone going to keep data around for a long time, they don't want it abstracted and encapsulated, they want concrete, exposed, well-defined representations with powerful operations for manipulating it. RDMBSs provide that. I think among the non-RDBMs systems, FramerD comes closest to that.
So, there are practical reasons why people don't use OODBMSs. But I think there are also some fundamental theoretical issues having to do with how data is manipulated and data models evolve. Still, OODBMSs have many attractive features, so one can hope that they will evolve to meet people's needs more. For some applications, they are already preferable.
Well, given that it was priced and marketed like a high-end, enterprise-grade database system, that kind of seems reasonable.
What we should have done from day one was to sell persistence for C++.
Indeed. But a persistence library for C++ might cost a few hundred dollars per developer and have no or minimal per copy runtime costs. ObjectStore was priced out of that market by orders of magnitude.
In addition to the license costs itself, there are training costs, retooling, and the cost associated with the risk of picking a single vendor solution. Even if you had given ObjectStore away for free it would have been difficult to displace RDBMSs.
The best chance for success I see these days would be to have a simple, reasonably good open source OODBMS and make money on management tools and high performance versions. Still not the stuff of billion dollar companies, but a decent living.
That strategy was necessary in some ways, because we were venture-funded, and the VCs weren't going to be happy with a small niche. They wanted something that would get into every insurance company and bank. However, by aiming high and failing (by VC standards), we abandoned our natural market too soon and avoided becoming a small success in that market.
It's unfortunate that good technology like ObjectStore failed, but ultimately the choice was yours when you accepted the money and the business model.
This is a little piece I wrote recently as an internal memo. We use Versant on an internal project, and wanted to justify the use of OODBMS. We want to begin supporting an open-source one, which is where this came in...
---
Premise:
When Java first started appearing in enterprise-wide systems, there were large existing systems containing the enterprise's data. Early on, for Java to have acceptance as a solution to problems in this domain, there had to be a way to access this data... data was not going to be 'recreated' for a new, unproven language.
By far, this data was stored in relational databases, like Oracle and Microsoft's Sql Server. The shortest path to accessing this data in a way that made sense to Java's cross-platform nature was to take an existing specification, ODBC, and create a java-specification based on it. Thus, JDBC was born.
In the years since then, JDBC has matured into a very usable API for accessing relational databases, and a lot of Java developers have had to learn how to use it. Many developers don't even realize it, but there is a mismatch between storing data as an object graph and storing it in a relational database. As a developer, you have to write a lot of code to map between the object world and the relational world. There is a better way.
JDBC is great for accessing existing relational data... It is and should be considered a bridge to legacy systems. If you are starting a new project using Java, there should be a better way. There should be a way to store your data without thinking about it. You should be able to hand your objects to a service that will store them. You should be able to maintain complex relationships between those objects, and you should be able to query that service for objects that match certain criteria. You should not have to muddy up your domain objects with code for storing themselves, and you shouldn't have to extend any objects that a framework provides. You shouldn't have to complicate your build process with 'enhancement' steps, and your objects should not be bytecode modified, so they are still usable in debugging environments.
Does such an object-oriented database exist? In some respects, yes. There are object-oriented databases such as Object Store and Versant. They operate very closely to the ideals listed above. But for most developers, especially those that already know JDBC, their price tags are a large barrier to entry. Until you know the technology, you won't recommend it. You won't recommend the technology until you use it. You are not going to spend $10,000 of your own money to get to know and use a product like this... there are too many other things happening in the Java community anyway.
Conclusion:
These are the reasons object databases have not become popular: There is a high barrier to entry for their use. The databases themselves are expensive. And Java Developers doing database access know JDBC, which is a 'good enough' solution.
In order to overcome this and make object databases take their position in the java community as a preferred way to store data, we need a good, Free, Open Source implementation with all the benefits of transparency of use. Once the database is Free, it must be evangelized by developers. Other developers need to know of it and learn it.
I just went through this decision-making process with the consultants who are going to build my company's OSS. While OODBMS were an obvious choice to me for performance and ease of programming, my consultants told me that finding Oracle talent was so much easier than finding Versant talent (for example) that I would be wasting time and money using OODBMS. This is especially true of DBAs.
Now, my reasons for not liking existing OODBMS solutions aren't necessarily reasons not to use them. My reasons are twofold, and both revolve around OODBMSs not really being very OO.
- Ultimately, an OODBMS is really storing primitive data types in a structured fashion and not much else. It's really storing more of a collection of C style STRUCTs than C++ Classes. The application that uses the database really provides the objects, it's just that the OODBMS makers play cute tricks to transparently (well, sort of) instantiate objects for you initialized with data from it's structured database. This is the heart of a lot of the non-reusability arguments. Now, if an OODBMS got smart and hooked up with something like COM or CORBA, then maybe you'd have something: then an OODBMS could do things that an RDBMS would find really hard.
- Related to the point above, OQL and queries and interacting with an OODBMS isn't OO. Again, it's just structs. Basically, to program with an OODBMS, you are forced to violate encapsulation. Say you want to search the database and pull out all of your 3D meshes with a volume greater than V. Now presume that you have conveniently made a mesh class that has a volume function that will iterate through sub meshes and the like to calculate the volume. Encapsulation at work, as you have no need to understand the internal organization of the meshes. So what I'd like to say in OQL is something like this: "SELECT m FROM meshes WHERE m.volume() > V". Unfortunately, the OODBMS has no clue what volume() is. Now, if you had member variables of length, width, and height, you could try: "SELECT m FROM meshes WHERE m.length*m.width*m.height > V". But again, this violates encapsulation really badly. What about spherical meshes? If they actually had an OO query language, then you could really save a lot of time and effort. Otherwise, the advantages of your carefully constructed classes not only don't apply, but they get in the way.
I guess in summation, I think OODBMSs could be really cool. I'd like to see an open source one at the same level of quality as MySQL (and yes, I would consider contributing, I'm just not an expert in such things). But until then, the cost and non-standardization will keep me away from them except for fun.Of course that's a personal problem
But there's a good reason why it stops my *good* use of an OODB.
If you look well and hard at C++, it's mildly object oriented, you can at least *create* objects, right?
If you look well and hard at Java (god bless it), it's *mostly* object oriented, at least there's a *root* object in the hierarchy, right?... Hmm, what are all those basic components though, is that an integer over there? What kind of object is that again?
Now then, if you managed to find a language whose native types were *all* expressed as objects, where my data were all most naturally expressed as an object (god bless Objective C and Scheme)... well, I'd be much more likely to store my data objectively (come to think of it, I do hate most of my data more than a little).
At any rate, I think the answer is that Object technology is only just coming into its own, and the rigor required of us the programmers to *USE* object orientation to its fullest extent is something that we don't enjoy doing for something as crunchy as DBMS access. Of course, just trying to get the data-creating departments to specify your data in an object oriented fashion might very well bite arse also...
Nietzsche on Diku:
sn; at god ba g
:Backstab >KILLS< god.
I worked for two years on a project in New York city that was trying to hold makket data using an O2 database. My experience has been that: The accounting people who wanted to generate reports using the tools they were used to (Crystal Reports, Excel, etc.) needed instead to ask the IS department to write programs that would generate flat files (rows and columns) so that the complex, non-tabular OO data could be brought back to tabular data for reporting purposes. Hell it would have been simpler and cheaper to have had the data in an RDBMS in the first place! Another problem was that changes to the schema routinely broke all of our apps. Performance was abysmal, and hiring people who had even heard about the O2 database was impossible. After two years the project was canned. Remember, it's a lot cheaper to make programmers map JDBC ResultSet to objects than it is to have them map OO data back to tabular format for reporting purposes. Your database is worth nothing if it does not support the needs of the business. The ability to be able to perform ad-hoc queries or to load a table in Excel is a must have for most enterprises.
full disclosure, I work for a ODBMS vendor, even worse I'm a marketing/business type (well with an engineering history) at an ODBMS vender.
Now for the 3 people who are still reading. It may surprise you but I and we (my company) agree with this RDBMS working coward to a large degree.
The premise of the parent article that positions RDBMSs and ODBMSs as direct alternatives for the same applications is flawed IMO. The fact is we make most of our sales on applications where we are replacing or competing with home grown database or caching solutions. If an RDBMS and an ODBMS are head to head technical competitors at the end of a prospect evaluation, one of them is in the wrong place.
Somebody will ask "Well both RDBMS and ODBMS are in the business of managing getting bits on and off disks enforcing ACID properties, what can be so different about the ODBMS applications that they can't use an RDBMS?" There is a simple answer. Performance and data model complexity, sometimes both. ODBMS's sell to customers who are modeling things that are so interrelated and complex that the task of transforming them at all to make them persistent and to share them among multiple users transactionally is inconceivable. Real time financial risk management systems, derivatives, simulation, optimization systems, document storage, Teleco network management, ECAD, CASE, CAD all examples. Do you think Intel is storing the designs, simulations and test systems for it's next chip in Oracle? How many people at once can work on the design for a chip with millions of transistors? Just one?
Also ODBMS are often the solution of choice where multi-tier application performance is gated by the time needed to access backend data sources (mainframe,Relational,legacy, etc). Once it becomes necessary for performance reasons to store, cache or warehouse data (think of it as work in progress inventory) in an intermediate datastore somewhere in the middle tier for, ODBMS's have a big advantage, the user by definition has a throughput problem, and the ODBMS will be a lot faster because the middle tier application will be based on components EJB, CORBA, using OO development languages. Application servers scale logic/behavior execution but if they are waiting on a query to the backend it won't matter how fast they execute.
Do I think these markets are as large and valuable as the market that RDBMS's address? No
Do I think they are large and growing and are on the cutting edge of new systems being automated?
YES
We stopped competing with RDBMS's about the time the products became mature enough to use. Say 1995.
Most of you have probably interacted with an ODBMS today, you just don't know it.
All of this cowards technical wacks, query languages, physical vs logical storage structure, gee RDBMSs are really good at some stuff duhh. Mostly these are comments on implementation details probably from the immature ODBMS he looked at in 1995. Some of them he is right about.
Take my word for it if you can use an RDBMS to solve your problem you probably should. Just don't assume that everybody has the same problem or that you won't have new *harder* problems in the future. The world is complex and most of it isn't automated and the parts that are automated are mostly the easy parts. Just common sense.
As far as the wonders of object/Relational highbred systems all I can say is, to a man with a hammer all the world is a nail. You can get screws to go in with a hammer but a screwdriver is more effective and more in keeping with the screw's purpose. You can also hammer in nails with a screw driver but a hammer is more effective. ODBMS companies all use RDBMS for CRM and accounting systems. RDBMS vendors may not know admit it but they are using (sometimes selling) ODBMS based applications as well. By the time ORDBMS systems are really competitive with ODBMS they *will* be ODBMSs. An Object Database is a far more general solution, it is childs play to make an ODBMS pretend to be an RDBMS the opposite is what is hard. General solutions can't be optimized for specific usage, because they are general. By the time the relational companies are done building ORDBMS that really compete with us O vs R will be a distinction without a difference. Change is slow and it takes a long time to build good, mature large software systems. Gee I bet some of you might already know this.
As far as all ODBMS companies going out of business, we have been around for 13 years and we are a lot larger then most people expect us to be. Even better, we don't have much (real) competition for the needs we address. We'll be around and improving.
Henry Parnell
Get real. This has nothing to do with Oracle's license price which incidentally they have lots of competition on from Mickeysoft. All of the license costs are incidental to the real price of a system.
:-).
New technology only gets adopted where it makes both economic and technical sense.
In reality economic and technical judgments are just two different ways of assessing the same thing. ODBMSs only get used where the data modeling and/or performance requirements make disproportionate subjective sense to the decision maker and they only have traction in applications long term where the subjective judgment maps to the objective (where the original decision maker's successor sees more good then harm in the fancy technical solution he/she inherits). Often the ODBMS is in effect competing with both a RDBMS and a commercial UNIX vendor since "throw more hardware at it" is a lot more acceptable solution to performance problems then anything as wild as an ODBMS. Linux and ODBMSs are natural pairings since they both make obvious economic sense but appear risky to business types.
The easiest cases are those where only a lunatic would think of using a relational system followed quickly by places where relational has already failed and the project is too important to abandon. The interesting thing is that ODBMS vendors can actually survive and in some cases prosper farming the rocky land left to them by the accepted RDBMS wisdom. Adverse times lead to rapid and arduous natural selection rewarding the fast & smart and killing the opposite. Hard times are good for the breed, unless they kill it off
Oh, I work for an ODBMS vendor.
The classical tabular API to an existing database may be very bland and poor in terms of immediate usefulness, but at the same time very predictable.
It's indeed weird at first glance that you have a first API (a table structure) and then at least one second one to provide useful services to the application (OO schema).
But then again, if you have ever needed to re-use the same data for different purposes, you know why this impedance problem is worthwhile solving.
This separate, predictable default API is like a life insurance.
With a product I developed, Dyanmic Data Objects for Java (tm) I can add to a database schema, adjust dynamic data object properties, make adjustments to a database table for html forms via an auxiliary tool I wrote, bounce the services, restart the httpd server (to refresh servlets) and see an immediate change of html forms without one single java compile!
No coding utopia exists! So let's deal with reality. But some tools are just easier than others when it comes to getting the real work done!
The real problem is that you cannot easily do aggregation for results display across multiple objects. E.g. Blue Martini abstracts you from the database using queries that result in objects, but what kind of objects represent aggretations?
I worked on some early XML content publishing systems and often talked about the system and the concept at conferences.
Every single time I mentioned that we were using Oracle, I got asked the OODMS question.
This makes great CONCEPTUAL sense. Your XML goes right into the OODMS, you can whip around the document tree, do amazing cross tag and partial document searches . . . it's just great!
But no one uses this method. The lack of standard toolsets, the (percieved or real) lack of a reliable track record and the general feeling that OODMSs are a dead-end, non-reusable resource have kept people away. Poet, OmniMark and others have all given up on their OODMS based content systems. No one bought them because they thought they wouldn't gain acceptance . . . and gee, they didn't.
So how do you bootstrap a great idea? Starting small and open is one way. Or find people within the major vendors and get them to adopt the idea. Steve Meunch at Oracle did some great work with Object Views and XML tools. Granted they are Java based and kinda slow at first, but they do allow you to OO work with Oracle.
It would be great to have universal and easy OODMSs and it really does make more sense - so it's just gotta happen, right?
Bar
From current Objectivity employee: I suggest that the reason finding OODBMS talent has never been an issue with our clients is that the need for DBAs is infinitesimal in comparison to RDBMS. That being said, we appreciate that the known issues of resources(for example, how could you possibly implement a database without a DBA) is more easy to accept and present to executives than the unknown of working with an OODBMS. That is one of the reasons that we are now offering our Java/NT product for download with technical support for a 90 day period. This is the full product and comes with a tutorial and sample code to build a single database. Sample code for building a truly distributed database (database running on multiple servers that present a single logical view) should be available by June. Go to http://www.objectivity.com/DevCentral/Download/ . Almost all of the posts here are absolutely crucial information for OODBMS companies are ever to achieve any substantive market share. The logic of the case is not enough when people are hanging their hopes and plans on the success of their idea and company. The arrogance of niche market players is common in software. You would never see such arrogance from a consumer goods company. The perceptions of all of the postings reveal that all purchases, however technical, are still emotional decisions. The sooner OODBMS companies understand this fact, the sooner we will see a double digit market.
Not being listed among the links, I would like to comment, how our object database solves some of the issues that are discussed here in a prejudiced way:
- schema evolution
We simply store a superset of all class schema versions. Objects stored with older versions simply have null values for newly added members. Recompilation is not necessary.
- administration
Using reflection, the class schema is analyzed on-the-fly. The administration effort is zero.
- immaturity of current object databases
Good point!
- queries
Our implementation uses query-by-example for equality comparisons. We are working on a specification for more complex queries:
http://www.odbms.org/soda/soda.zip
- performance
Insert performance beats any relational approach by powers of 10 since we kick out all driver overhead. A benchmark comes with the download. Query performance is still deficient since we don't use indices yet, but we will get there.
- database design
Your class model says it all. There is no need to apply a second view not capable of inheritance.
- complexity
Our interface consists of 3 classes with 17 functions. Take tonight to learn it all.
- samples
...are available with the download
- price
Our product is free for non-commercial use.
Kind regards,
Carl
---
Carl Rosenberger
db4o - database for objects
http://www.db4o.com
db4o - open source object database for Java and
Two large lists of ODBMS:
http://www.javaskyline.com/database.html#odbms
http://www.cetus-links.org/oo_db_systems_1.html
ozone is open source
db4o is free for non-commercial
db4o - open source object database for Java and
Because object databases have been my business for the last fourteen years, I'm always interested in seeing what people have to say about them. I wasn't surprised to see some strong feelings and misconceptions expressed here, because that's something that's been going on for at least the last fourteen years. With all the experience that I have had with this technology, I feel compelled to write a few things.
First, by way of disclosure, my name is Doug Barry. I work as a consultant in the area of strategic database planning and decision-making. Basically, I help companies understand what object database and object-relational mapping products do, determine if the technology is the right choice for the companies, and focus on which product(s) best meet their application needs. I do this by publishing data books that compare object database and object-relational mapping products in what I call "excruciating detail," conducting training sessions, and providing consulting on product selection. I also serve as the Chair of the Object Data Management Group.
I want to add a few facts to this discussion. First of all, it is not correct to lump all object database products into the same category. Those who are deeply familiar with relational database products will tell you the same thing about those products. All products are not the same. So the general negative comments about object database products concerning such things as recompiling for schema changes, ad hoc queries, product stability, ease of use, etc. do not apply equally to all products. Such sweeping generalizations, like most generalizations, are inherently unfair.
Second, an object database is not the answer in all situations, just as a relational database is not the answer in every situation nor is any technology for that matter. An object database can be an excellent choice in situations where a client has a business need for high performance on complex data. The key here is selecting the best object database to fit the application needs. (There is more information on when to use an object database and related topics at one of my web sites, http://www.odbmsfacts.com/articles).
Third, object databases have become part of our everyday life and few people know this. They are in many applications, such as stock trading, airline ticket sales, voice mail systems, cell phones, pagers, and a wide variety of web sites. Most of my clients who use this technology see it as a competitive advantage and part of their proprietary design and do not publicize its use. They market the features of their product or service, not the technology to make it run. This has created a false impression that object database products are not part of the mainstream technology choices; they are.
One of my clients has gone public with the way in which it uses an object database. That client is the Chicago Stock Exchange. If you are interested in seeing an application architecture that uses an object database, go to the CHX Technical Roadmap. Look at the architecture diagram in the upper right hand corner on page 3. This design is not unusual. It is a multi-tier design where the object database is used for a high-performance trading engine in the middle-tier. At the end of the trading day, the data is written to Oracle for various back-office processing that has grown up around the Oracle database over the years.
As I tell my clients, the bottom line in any type of database design (relational or object), is that you need to deeply understand your data and how you use your data. From that understanding, it is possible to match product features to your application needs in order to increase your chance of success. Sometimes, that best chance of success is with an object database product.
The term "object-oriented database" means many different things to different people, so there is no one way to reply to the wide range of things being said here about them. The best I can do is present my own personal view, which should not be taken as an official statement of my employer.
The most important thing I want to say is that I don't agree with the original article's assertion that, in general, people who are using relational database systems ought to be using object-oriented database systems.
Way back in 1988 when the original engineering team first started to design ObjectStore, we had no intentions (or illusions) of replacing relational database systems. Rather, our purpose was to create a data management system suitable for certain applications that, so far, had not found existing data management systems to be appropriate. There were many examples of these, but just to keep things simple I'll focus on the one that was most representative: computed-aided design (CAD).
In 1988, no leading CAD system was using relational database systems to model their most fundamental data, such as transistors, connections between electronic parts, traces on PC boards, electronic schematic diagrams, and so on. As far as I know, production CAD systems still aren't using relational databases for this purpose.
Our goal was to design a data management system suitable for CAD (and other applications) for which RDBMS's didn't seem to be doing the job. Why? Because they had a very different set of requirements, and they needed a different tool to do a different job. The only way to understand what we were up to and where we were coming from is to think carefully about our target market, and how different it was from the traditional RDBMS target market.
ObjectStore was originally designed with goals in mind such as:
(1) Be familiar to the programmers who develop things like CAD systems. At the time, C-based object-oriented programming langauges such as C++ and Objective C were starting to emerge, as the programming world started to see the benefits of "object-oriented programming", or, at least, the useful data modelling capabilities provided by OOP. We bet that C++ would probably catch on in our target markets, and I think we turned out to be right. So our goal was to make a system that would be easy to use for programmers trained in C++. We wanted to say that you could program very much as you are accustomted to program, and with a little extra effort, it can all be stored away automatically. (We didn't care about people trained in SQL: they were not our target market.) Also, make it as easy as possible to use your existing base of C++ code with the new data management system (i.e. we cared a lot about pre-existing code; the issue of pre-existing relationsl databases wasn't an issue for our target market). Integration with the programming language was way up high in our list of goals.
(2) Optimize performance for cases in which there was excellent spatial locality of reference and excellent temporal locality of reference. This is true of the typical CAD application. An example of the kind of thing we wanted to benchmark well on was: "Redisplay the screen, with lots and lots of transistors and resistors and capacitors and wires connecting them all" (or whatever, depending on the electronics technology in question). (We didn't care about TPC benchmarks: that was not our target market.) Imagine what the code looks like to redisplay the screen. Now imagine if every time you wanted to know "what wires are connected to this transistor", you had to put together an SQL string, the SQL string had to be sent over a network to a database server, the server had to parse the SQL string, the server had to run the query optimizer over the SQL string, the server had to find the appropriate pages in its data cache, etc, etc, etc. In ObjectStore the whole thing happens in a few CPU instructions. This one example of where we get huge performance gains.
(3) Provide real ACID transactions. (Yes, of course programmers had to think about transactions, and where the transaction boundaries should be, and what transactional consistency meant in their system: that's necessary for dealing with concurrency and recovery consideration. We didn't promise that you'd program exactly as you did pre-database-system; but we made it as close as possible.)
(4) Provide simple associative queries, with automatic optimization, subject to goal (1), i.e. make the query language natural for C++ programmers. It was not a goal to support some of the fancier queries that SQL can do; that didn't seem to be too important to our target market.
(5) Be able to provide fast navigation through database objects, just as any modern programming langauge lets you navigate quickly through programming language objects. Many of the most basic, inner-loop computations that programers in our target market wanted to do would, if expressed in SQL, use five-way or seven-way or ten-way joins, which existing commercial RDBMS's handled very poorly. (Ten-way joins look just find in Codd's mathematical structures, and you could conceive of ways to implement an RDBMS that would do much better at them, but it would be hard, and as far as I know it hasn't been done; Oracle's traditional target market didn't much care about them.)
(6) Distribute the use of CPU resources. The CAD people were moving in the direction of using what were then called "workstation"-class computers, connected by local-area networks, in which the "client" workstations had a great deal of processing power and memory (by the standards of the time), and it made sense to take advantage of that.
We were not the only people thinking this way. There were many, many papers published by university and corporate researchers, saying the same things. Our principal competitors, as far as I've ever been able to tell, were using the same general principals. The benchmarks that our customers used to evaluate us were obviously designed around these same assumptions.
Let me point out again that "object-oriented database system" means many things to many people: the list of goals that I gave above is certainly not what a lot of people mean by OODBMS!
Now, as it happens, most of the leading CAD vendors did not end up buying ObjectStore and building CAD systems based on it. If you look, you'll find that they are using pretty much the same technology now that they were using twelve years ago. At the time, many of them were talking about upgrading to use some kind of data mangement system, very much like what we were talking about: we were in touch with the CAD company engineers and spent a lot of time talking to them about what they wanted. Unfortunately, for various business reasons, most of them did not move ahead with major advances to their technical underpinnings. (That said, there were some new CAD companies that did created CAD systems based on ObjectStore, some of which are still being sold today.)
In particular, the locality-related optimizations (point 2 above) were fundamental in our overall design. In our classic use case, one user would access a hunk of information, and pretty much all of it would get cached on his powerful workstation, and would be operated on at the powerful local workstation for a considerable period of time. So it made a lot of sense to move a good deal of processing to the client side, and try to minimize the burden on the (shared) server.
There are plenty of tradeoffs involved in these optimizations. For applications without that kind of locality, they aren't optimizations at all. Also, basic pure ObjectStore does a lot less runtime error-checking than it might, because the CAD engineers specifically did not want to pay for that kind of runtime error-checking, at least from what we learned. (Note that there are other OODBMS's that make very different choices here; much of what I'm saying, especially about performance issues, should not be taken to apply to anything besides ObjectStore.)
We built a different tool to solve a different problem. So all the arguments of the form "relational database experts are easier to find and hire than OO database experts" are true, and probably good answers to the original article, but aren't relevant to our business, because we were not trying to replace relational databases for what relational databases are good at.
Similarly, if I may indulge in sarcasm for a moment, not every collection of human beings on the planet Earth have (a) already learned about expressing data in normal form (which is really quite un-obvious until you study it) and already learned SQL, and (b) have no idea how to program in any modern programming language. Some people are skilled C++ programmers who have never used a relational database system in their life.
I still think we did a pretty good job of what we originally set out to do. As things developed, though, we ended up with a far more diverse and heterogeneous set of customers than we had originally expected: lots of telecommunications, lots of financial applications, and all sorts of exotic stuff. Our customers have tried to use ObjectStore as part of all kinds of software systems, many of them really cool and innovative and not falling into any traditional category at all. Some of them had requirements that were pretty much like the ones above; some had very different requirements. We did a good job for some of them and a not-so-good job for others. In my personal opinion, we had trouble developing ObjectStore because our requirement set became so diffuse; that is, everybody was asking for something different.
There turned out to be some applications in a middle ground between what we designed for, and what relational database have traditionally been used for. So this complicated things a lot, and meant that sometimes ObjectStore was being asked to do things too far away from what its original design was intended for. One thing I'll 'fess up to is that I think in the past our company sometimes tried to sell ObjectStore for applications that were too far away from the original design goals, and so sometimes it would turn out that ObjectStore just wasn't the right tool for the job. I think we're a lot better about that these days then we used to be. And we've found more areas in which our kind of system turns out to be a good and appropriate tool.
I can't reply to everything everyone has said. And a lot of what has been said, rightly, has been directed at the original article, whose points are very different from my own.
But, here are some for which I think a reply is needed:
To "sailesh" the IBM DB/2 engineer:
- Your statement that you can't do a range query is completely wrong. ObjectStore has supported B-tree indexes and range queries since its first release.
- You say "Relational databases are great at recovery of your data using log information". So is ObjectStore. It uses write-ahead logging and recovers just fine, and has done so since its first release.
- "Actually, academia has well and truly come to the conclusion that RDBMS technology is the way to go." There isn't any one single way to go, any more than there is one single best programming language. I am still waiting to see an interactive CAD system that models its basic items using relations. If IBM's CAD sytems are now using DB/2 at this level, please let me know. As for academia, they have largely lost interest in the whole issue and moved on to other things.
To "micromoog", who said "Given the dramatically higher costs associated with designing and maintaining an OO system, most applications just don't need the incremental performance gains associated with it." I completely deny the claim that designing and maintaining OO systems has a "dramatically higher cost". Taking a bunch of guys who know COBOL and SQL, and try to dump C++ on them, sure, that won't work very well. But the whole point of OO systems is to make design and maintenance easier and cheaper, and I certainly belive that they succeed that way. Why do you think nearly every serious programming langauge successfully introduced in the last ten years has included OO programming? And the performance gains for using ObjectStore as opposed to an RDBMS, for those applications for which ObjectStore is suitable, are not "incremental"; they can easily be 100x or 1000x.
To the small number of people who claim to have used ObjectStore and had all kinds of trouble with it: well, I'm really sorry that was your experience. We have certainly had many customers who've been quite successful with ObjectStore. We've had a lot of repeat business. I've been involved with our support organization to know that the great majority of user experiences were not nearly as bad as the ones you report.
To the people who complain that OODBMS's give you a problem with "vendor lock-in": well, there's a lot of truth in that. There aren't good standards among commercial OODBMS's, largely due to fundamental and irreconcilable philosophical differences, and different choices made on certain major engineering tradeoffs. On the other hand, it's pretty late in the day to claim that's it's easy to switch among commercial relational database systems. They are each full of handy features that no other vendor supports. They all have different SQL dialects with different extensions to the query language. And, of course, they all have entirely different data storage formats. How many times have you heard of an IT organization that decided one day to switch from Oracle to Sybase or from DM2 to MS SQL Server? Yes, it happens sometimes, but it's hardly something one guy does in an hour.
To "Pedrito", who is in the business of selling applications designed to work with the customer's existing database system, and for which relational database systems are approriate: yes, certainly you should be designing your applications to work with relational database systems.
To the people who say that the problem with OODBMS's is that "there isn't one single object model" or "objects lack the theoretical underpinnings of Relational Algebra": gee, then why don't we use relations as the fundamental data model of all our programming languages? Really, the significance of the "mathematical underpinnings" business often seems to take on spiritual or mystical dimensions. From the point of view of our CAD engineer, there's a tradeoff between (1) having a sophisticated ad-hoc query language that lets you express complex queries that you never anticipated, and (2) getting that screen to redisplay nice and fast. It would be great if you could have both. I have yet to see how to do that. Maybe someone else will figure it out. As an engineer, you learn about the concept of "engineering tradeoffs". A design approach that's best at one thing often isn't best at another thing.
As for me, I decided that nine years of working on ObjectStore was enough; I liked doing it but one needs variety in life. I am now working on our XML-based business-to-business integration server product. It's based on our XML information management product, which is based on ObjectStore internally (but invisibly to its users). So I've been rather far from the actual ObjectStore business of the last several years. So I don't feel comfortable trying to summarize "how it all turned out". I know that we have lots of customers using ObjectStore together with relational databases, letting each do what it does best, and maybe that's one place that object-oriented databases are headed.