Controlling Object Property Breadth
You may also want to limit how much data you retrieve from a given object. A complex object may consist of 20, 30, or even 50 or more properties, including embedded objects and lists or arrays of objects. What if you only need access to one or two of those properties? Isn't it overkill to instantiate the entire object, populating 50 properties in order to get two of them? If you're retrieving a list of such objects, you could end up with an array of 200 objects - along with all 50 of their properties - when all you need or want is one or two properties per object.

What's needed is a mechanism for controlling object property coverage.

One approach is to define a POJO that only defines a subset of the properties in the original object and populate it. This is where a relational database has an advantage over an object database. You can use JDBC to retrieve just the data you want and populate the POJO. "SELECT firstName, LastName FROM PERSON WHERE ID = 1"

Hibernate
Since Hibernate is typically backed by a relational database, it provides excellent control over your object property coverage. You can define a SELECT statement that only retrieves the properties you're interested in and provides them to you as a Java List or a List of Object Arrays.

DB4O
DB4O is a pure object database, so you must instantiate the object to access its properties. DB4O provides no help for you on this score.

Caché
Besides the Object interface that Caché provides, it also provides an SQL projection or interface. This lets you access objects as if they were tables and columns in a relational database. Using this method, Caché provides excellent control over your object property breadth.

Object Tree Traversal
Once you have your objects, you want to be able to traverse the object tree. For example, if you start with an employee, you want to be able to access the company name as follows:

employee.getDepartment().getCompany().getName().

This is one of the most powerful features of object-oriented development and one of the strongest arguments for using an object database.

Hibernate
Unfortunately relational databases provide virtually no support for this type of functionality - normally you'd have to issue SQL SELECTs to retrieve additional data as needed and create the associated POJOs. Fortunately, Hibernate provides this functionality for you by providing a proxy object to fetch additional mapped objects as needed. This works as long as you have a valid Hibernate session object available.

DB4O and Caché
Since they are object databases to begin with, DB4O and Caché handle this with aplomb. As you make calls to related objects, they're automatically retrieved from the database. Thus you can access your objects as follows:

employee.getDepartment().getCompany().getName();

List myEmployees = department.getEmployees();

And so on.

Enforcement of Referential Integrity
How can you ensure you don't delete an object that other objects depend on? For example, can you delete a department if the employees still exist? Does it support cascade deletes/updates?

Hibernate
While you can define relationships using Hibernate annotations, the actual support and enforcement of referential integrity is dependent on the database used on the back-end.

DB4O
DB4O currently doesn't enforce referential integrity.

Caché
Caché provides full support for maintaining referential integrity, as well as for performing cascade updates and deletes. This can be controlled based on the way you define the relationships. One-to-many relationships enforce referential integrity, but don't perform cascade updates and deletion. Parent-Child relationships enforce referential integrity and provide cascade update and deletion functionality as well.

Enforcement Of Uniqueness
How do you ensure that specific properties are unique in the database, such as Social Security numbers?

Hibernate
Support for marking properties unique and enforcing it is supported by most databases used as a back-end for Hibernate.

DB4O
DB4O currently doesn't provide any support for enforcing uniqueness. This feature is currently undergoing beta testing and the tentative release date is round mid-summer 2007.

Caché
You can mark as many properties unique as you want.