Increasing agility with NoSQL - Making Sense of NoSQL - page 199

exists in the group's ability to fairly compare effort. If there are disputes on the rela-
tive effort, you may need to write sample code for some use cases. Although this takes
time and slows a selection process, it's sometimes necessary to fairly evaluate alterna-
tives and validate objective effort comparisons.
Many organizations that are comparing RDBMS s and document stores find a signif-
icant reduction in effort in use cases that focus on data import and export. In our next
section, we'll focus on a detailed analysis of the translations RDBMS s need to convert
data to and from natural business objects.

9.3 Using document stores

to avoid object-relational mapping
You may be familiar with the saying “ A clever person solves a problem. A wise person avoids
it. ” Organizations that adopt document stores to avoid an object-relational layer are
wise indeed. The conversion of object hierarchies to and from rigid tabular structures
can be one of most vexing problems in building applications. Avoiding the object-
relational layer mapping is a primary reason developer productivity increases when
using NoSQL systems.
Early computer systems used in business focused on the management of financial
and accounting data. This tabular data was represented in a flat file of consistent rows
and columns. For example, financial systems stored general ledger data in a series of
columns and rows that represented debits and credits. These systems were easy to
model, the data was extremely consistent, and the variability between how customers
stored financial information was minimal.
Later, other departments began to see how storing and analyzing data could help
them manage inventory and make better business decisions. For many departments,
the types of data captured and stored needed to change. A simple tabular structure
could no longer meet the organization's needs. Engineers did what they do best: they
attempted to work within their existing structure to accommodate the new require-
ments. After all, they had a sizeable investment in people and systems, so they wanted
to use the same RDBMS used in accounting.
As things evolved, business components were represented in a middle tier using
object models. Object models were more flexible than the original punch card mod-
els, as they naturally represented the way business entities were stored. Objects could
contain other objects, which could in turn contain additional objects. To save the state
of an object, many SQL statements would need to be generated to save and reassemble
objects. In the late 1990s these objects also needed to be viewed and edited using a
web browser, sometimes requiring additional translations.
The most common design was to create a four-step translation process, as shown in
figure 9.5.
If you think this four-step translation process is complex, it can be. Let's see how
you might compare the four-translation pain to putting away your clothing.