The pattern demonstrates a way to map objects to a single database table using BLOBs. The pattern covers inheritance, aggregation, and associations. It is interesting from an academic point of view and as a source of ideas to solve unusual problems in mapping objects to relational databases.
How do you map objects to a relational database?
The forces are identical to those discussed with the One Inheritance Tree One Table pattern.
Use a table containing two fields: One for the synthetic OID and a second one for a variable length BLOB that contains all the data an object holds. Use streaming to unload the object’s data to the BLOB.
The
table design for our running example or any other example looks exactly like the
above table design.
Write and update performance: Objects in BLOBs allows reading and writing of any BaseClass descendant with a single database operation. Note that BLOBs are not the fastest way to access data types in many RDBMS.
Polymorphic reads: Scanning classes for properties is difficult. As you do not have access to the internal structure of the BLOB you need to register functions with the database that give you access to the attributes. See [Loh+91] on how to implement such functions. Defining and maintaining these functions costs as much or even more effort as using database fields from the beginning.
Ad-hoc queries: As scanning classes for properties is difficult, ad-hoc queries are also difficult to express. Again additional functions need to be defined.
Space consumption: If your database allows variable length BLOBs, space consumption is optimal.
Maintenance cost: Schema evolution is comparable to schema evolution in an object oriented database.
Sources of similar implementations: Objects in BLOBs has been used in research prototypes. These tried to come as close as possible to a OODBMS using a relational database as storage manager. Hence implementing the pattern is very similar to implementing an OODBMS on top of a existing storage manager.
Balancing of database load across tables: Mapping too many classes to a single table results in poor performance. For a discussion see the Consequences Section of the One Inheritance Tree One Table pattern.
Combining OODB properties with relational databases: It is feasible to combine this pattern with other types of object/relational mappings. In this case the BLOB would hold complex object structures, like a project planning chart. Additional fields would hold the information needed to access the organizational data via normal ad-hoc queries (see Figure 3 ). Objects in BLOBs has been used in the SMRC research prototype [Rei+94, Rei+96]. The BLOBs in SMRC do not only hold a single classes’ attributes but may contain a whole net of objects streamed to a BLOB (as depicted in Figure 3). The approach is used to allow coexistence of relational and OODBMS data in a single database. The approach is not exactly used in the pure form we describe in the above pattern.
Figure
3:
Coexistence of Object Data and Relational Data (picture adapted from [Rei+94])
Used in a pure form, the pattern is similar to the One Inheritance Tree One Table mapping. See also Representing Inheritance in a Relational Database [Bro+96].
Fowler calls this the Serialized LOB pattern on his site.