Object Oriented Databases Physical Data Placement

Physical Data Placement: Now that we have our schema, we can now think about how we want to organize our objects on our physical storage. With almost all SQL databases, it’s assumed that the physical placement of the data will follow the table structure and be organized by type.

For this application and many others, however, it doesn’t make sense to store the data purely by type for several reasons.

For example, messages have a very strong temporal component, but there may be many different kinds of messages. In our initial schema design, we assume that there is only a single type of message, but we’d like to be able to expand the application to subtype message into many different kinds without affecting our queries.

On the other hand, message and address objects are of different types, but are tightly related. Rather than separate these objects, we’d like to group these as “composite” objects and possibly organize them by attributes appropriate to these, like last name.

The difference between Objectivity/DB and other solutions is not that Objectivity/DB requires a physical design. The difference is that Objectivity/DB allows more customization and is less restricted to defining the physical strategy according to type.