Foundational data architecture patterns - Making Sense of NoSQL - page 43

Table 3.1 (continued)

Feature Strength Weakness

Fixed data definitions and
typed columns

Easy way to define structure and
enforce business rules when tables are
created. You can verify on insert that all
data conforms to specific rules. Allows
range indexes over columns.

Difficult to work with highly
variable and exception data
when adding to a column.

Fine-grained security Data access control by row and column

can be done with a series of view and
grant statements.

Setup and testing security
access for many roles can be
a complex process.

Document integration None. Few RDBMSs are designed to

easily query document structures.

Difficult to create reports
using both structured and
unstructured data.

We should note that RDBMS s are continuing to evolve to add finer-grained control of
ACID transactions. Some RDBMS s allow you to specify the isolation level of a transac-
tion using a command such as SET TRANSACTION ISOLATION LEVEL READ UNCOMMIT-
TED . Setting this option performs a dirty read or a read on data that hasn't yet been
committed. If you add this option to a transaction, reports may have inconsistent
results, but they can return faster, which can result in increased read performance.
When you look back at the information in this section, you can see that the needs
of ERP systems were influential in the RDBMS feature sets of today. This means that if
your business system has requirements that are similar to an ERP system, then an
RDBMS might be the right choice for you. Now let's take a closer look at how these sys-
tems worked by using a sales order tracking example.

3.3 Example: Using joins in a sales order

Now that you know about row stores and how they work, we'll talk about how RDBMS s
use joins to create reports using data from multiple tables. As you'll see, joins are flex-
ible from a reporting perspective, but create challenges when trying to scale RDBMS s
to multiple processors. Understanding joins is important since most NoSQL architec-
ture patterns are free of joins (with the exception of graph patterns, discussed in
chapter 4). The lack of joins allows NoSQL solutions to resolve the scalability problem
associated with single-processor systems by scaling across multiple systems.
A join is a process of using a row identifier in a column of one table to reference a
particular row in another table. Relational databases are designed to find ways to cre-
ate relationships between tables of related data. The classic RDBMS example is a sales
order tracking system similar to a virtual shopping cart you'll find on amazon.com.
See figure 3.4 as an example of how the data associated with a sales order might be
represented in an RDBMS .