Core Java Data Objects

Unlike JDBC, which is specific to databases that support SQL, JDO is datastore-neutral. The same JDO application can be used with a relational database, an object database, a flatfile, or even an in-memory database. A JDO implementation for the underlying datastore being used is all that's required.

Although the application itself remains the same across databases, how a database is set up and used with a JDO implementation varies. The JDO specification does not define how a persistence-capable class is actually mapped to its representation in the underlying datastore; this is left to the JDO implementation. Typically, before a JDO application can be run, the following steps must be performed:

• Specify the mapping between the persistence-capable classes and the data-store schema. JDO implementations typically use the extension element in the JDO metadata to specify the mapping between the persistence-capable class and its representation in the datastore, and provide tools that can be used to generate this mapping.

• Create a database, and define the schema. Again, JDO implementations typically provide tools that can be used to define the schema in the database.

How each step is performed varies between JDO implementations; an implementation's documentation should be consulted for further details.

7.2.1 Using JDO with a relational database

There are three approaches to using JDO with a relational database:

• Define the persistence-capable classes, and generate the database schema.

• Define the database schema, and generate the persistence-capable classes.

• Define the persistence-capable classes and database schema independently, and define a mapping between the two.

The first approach is suitable for applications in which there is no existing database and the application is free to define its own schema. The database schema can be generated from the persistence-capable classes. This has the advantage that the application can leverage the power of object-orientation when defining its persistence-capable classes. A JDO implementation's tools are used to automatically define the schema in the database for the persistence-capable classes and to create the mapping specification between the persistence-capable classes and the schema.

The second approach is suitable for applications in which a database already exists and the application must use the existing schema. The persistence-capable classes can be generated from the schema. This has the advantage that a JDO application can easily access existing data in a database; however, the generated classes won't be particularly object-oriented in nature. A JDO implementation's tools are used to generate the Java classes from the database schema for the application and to create the mapping specification between the persistence-capable classes and the schema.

The third approach is suitable for applications in which both the persistence-capable classes and the database schema already exist. A mapping is specified between the persistence-capable classes and the existing database schema. This has the advantage that a JDO application can leverage the power of object-orientation when defining its persistence-capable classes but can still access existing data in a database. A JDO implementation's tools are used to define the mapping between the persistence-capable classes and the database schema. This approach is the most complex of the three because defining a mapping between two arbitrary models is a difficult task. Typically, for this approach to work, the persistence-capable classes and database schema must have a similar structure.

A JDO implementation that supports relational databases may not support all the approaches outlined. Developers must choose an implementation that supports the approach required by their applications.

7.2.2 Using JDO with an object database

Object databases differ from relational databases in that they do not use the relational model (tables, columns , and rows) to store data; instead, they use the object model (classes, fields, and instances). Direct support for the object model means that a JDO persistence-capable class can be mapped directly to its object representation in the database.

The approach to using an object database with JDO is similar to the first approach outlined for using a relational database. The persistence-capable classes are defined, and the database schema is generated. A JDO implementation's tools are used to define the schema in the database for the persistence-capable classes. There is typically no mapping to specify because the persistence-capable classes map one-for-one to the classes defined in the database.

7.2.3 Object versus relational databases

As with most things, no single technology is best for all needs. Although a heated debate has taken place over the years about the pros and cons of using object versus relational databases, much of it has failed to recognize that the different technologies satisfy different needs. This doesn't necessarily make one technology better than the other; it simply means that a developer must understand which is most appropriate for the job at hand.

The primary strength of an object database is its ability to manage arbitrarily complex object models, including the following:

• Inheritance

• Multi-valued fields (arrays of values)

• One-to-one, one-to-many, and bi-directional relationships

• Relationships that include semanticssets (uniqueness), lists (ordering), and maps (associative lookup)where the relationships may be complex objects in themselves , perhaps containing hashed values for efficient in-memory lookup and retrieval

Complex object models are typically hard to map to an efficient representation in a relational database, and because an object database is able to directly represent a persistence-capable class without any mapping, a JDO application gets the following benefits:

• Development: Additional metadata is not required to specify how a persistence-capable class should be represented in the database. This may appear only a minor benefit, but as the number of persistence-capable classes increases along with the complexity of those classes (use of inheritance and relationships), the additional metadata can add up.

• Performance: Because the persistence-capable classes are directly represented in the database, there is less overhead to retrieve a persistent object (if using a relational database, it is likely that the representation of a persistence-capable class would require several tables). As the complexity of the classes increases, typically the performance delta between relational and object databases increases.

Although a discussion of the relative merits of object and relational databases is beyond the scope of this book, a simple perspective is that an object database can be very effective as an application-specific database, whereas a relational database is a much better choice as an enterprise-wide database. Essentially, if an application persists data for its own needs only, an object database can be a good candidate. If an application needs to persist data to be accessed enterprise-wide, then a relational database is a good choice.