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 .
Search WWH ::




Custom Search