Database Reference
In-Depth Information
look up the node by URL and then perform type-specific formatting to display it. In a rela-
tional database, we might execute something like the following:
SELECT
SELECT
nodes
.
node_id
,
nodes
.
title
,
nodes
.
type
type
,
pages
.
text
,
photos
.
content
FROM
FROM
nodes
LEFT
LEFT JOIN
JOIN
pages
OON
nodes
.
node_id
=
pages
.
node_id
LEFT
LEFT JOIN
JOIN
photos
OON
nodes
.
node_id
=
pages
.
node_id
WHERE
WHERE
url
=
:
url
;
Notice in particular that we are performing a three-way join, which will slow down the query
substantially.Ofcourse,wecouldhavechosenthesingle-tablemodel,inwhichcaseourquery
is quite simple:
SELECT
SELECT
*
FROM
FROM
nodes
WHERE
WHERE
url
=
:
url
;
In the single-table inheritance model, however, we still retain the drawback of large amounts
of wasted space in each row. If we had chosen the concrete-table inheritance model, we would
actually have to perform a query for
each type
of content node:
SELECT
SELECT
*
FROM
FROM
pages
WHERE
WHERE
url
=
:
url
;
SELECT
SELECT
*
FROM
FROM
photos
WHERE
WHERE
url
=
:
url
;
In MongoDB, the query is as simple as the single-table model, with the efficiency of the
concrete-table model:
db
.
nodes
.
find_one
({
url
:
url
})
Polymorphic Schemas Enable Schema Evolution
When developing a database-driven application, one concern that programmers must take into
account is
schema evolution
. Typically, this is taken care of using a set of
migration
scripts
that upgrade the database from one version of a schema to another. Before an application is
actually deployed with “live” data, the “migrations” may consist of dropping the database and
re-creating it with a new schema. Once your application is live and populated with customer
data,however,schema changesrequirecomplex migration scriptstochangethe
format
ofdata
while preserving its
content
.