Polymorphic Schemas - MongoDB Applied Design Patterns - page 18

▪ Access controls for the object

Some of the fields, of course, will be distinct. The photo doesn't need to have a long markup
field containing its text, and the wiki page doesn't need to have a large binary field containing
the photo data. In a relational database, there are several options for modeling such an inher-
itance hierarchy:

▪ We could create a single table containing a union of all the fields that any object in the
hierarchy might contain, but this is wasteful of space since no row will populate all its
fields.

▪ We could create a table for each concrete instance (in this case, photo and wiki page), but
this introduces redundancy in our schema (anything in common between photos and wiki
pages) as well as complicating any type of query where we want to retrieve all content
“nodes” (including photos and wiki pages).

▪ We could create a common table for a base content “node” class that we join with an ap-
propriate concrete table. This is referred to as polymorphic inheritance modeling, and re-
moves the redundancy from the concrete-table approach without wasting the space of the
single-table approach.

If we assume the polymorphic approach, we might end up with a schema similar to that shown
in Table 2-1 , Table 2-2 , and Table 2-3 .

Table 2-1. “Nodes” table

node_id title url type

1 Welcome / page

2 About /about page

3 Cool Photo /photo.jpg photo